Slashdot Mirror

It would seem that you can automatically extract that kind of information without "linking" to it at all. For example, WWW::Mechanize is a way to create a virtual browser that could even start at www.orbitz.com, follow links and/or fill out forms, meanwhile providing all cookie/referer information Orbitz needs, to get whatever data you need.

If you don't create a link, can you call it deep linking?

I'd prefer they just stored it in plain text over proprietry binary formats, no matter how open they are.

If you use Perl then there are DBI modules (DBD::AnyData, DBD::CSV) to have a SQL frontend to plain text files (fixed length formats, variable width comma- (CSV), tab-, pipe-, colon- or anything-separated values, paragraph records, XML...). It's easy to use, and even quite fast. Great for writing simple apps that one day might need more traffic/data. Need more throughput? Just change the connect to use DBD::SQLite. Want a bigger RDBMS? Just change it to use MySQL or PostgreSQL. etc. When you use DBD::AnyData for simple programs with small data sets, you have your data in text format great for processing with grep/sed/awk textutils or even manually with your $EDITOR of choice (vi or Emacs) and yet scalable to giant data sets on Oracle with only one line of your app to change if you write it correctly in the first place. Great stuff.

I'd prefer they just stored it in plain text over proprietry binary formats, no matter how open they are.

If you use Perl then there are DBI modules (DBD::AnyData, DBD::CSV) to have a SQL frontend to plain text files (fixed length formats, variable width comma- (CSV), tab-, pipe-, colon- or anything-separated values, paragraph records, XML...). It's easy to use, and even quite fast. Great for writing simple apps that one day might need more traffic/data. Need more throughput? Just change the connect to use DBD::SQLite. Want a bigger RDBMS? Just change it to use MySQL or PostgreSQL. etc. When you use DBD::AnyData for simple programs with small data sets, you have your data in text format great for processing with grep/sed/awk textutils or even manually with your $EDITOR of choice (vi or Emacs) and yet scalable to giant data sets on Oracle with only one line of your app to change if you write it correctly in the first place. Great stuff.

I'd prefer they just stored it in plain text over proprietry binary formats, no matter how open they are.

If you use Perl then there are DBI modules (DBD::AnyData, DBD::CSV) to have a SQL frontend to plain text files (fixed length formats, variable width comma- (CSV), tab-, pipe-, colon- or anything-separated values, paragraph records, XML...). It's easy to use, and even quite fast. Great for writing simple apps that one day might need more traffic/data. Need more throughput? Just change the connect to use DBD::SQLite. Want a bigger RDBMS? Just change it to use MySQL or PostgreSQL. etc. When you use DBD::AnyData for simple programs with small data sets, you have your data in text format great for processing with grep/sed/awk textutils or even manually with your $EDITOR of choice (vi or Emacs) and yet scalable to giant data sets on Oracle with only one line of your app to change if you write it correctly in the first place. Great stuff.

what about postgresql?

That is a very good question, I don't know why has it been moderated as off-topic. Naturally it is useless to compare MySQL performance to MySQL performance ignoring any other options. (It is essentially the same tactic Micro$oft is doing all the time! Do we really want to parrot them?) First of all, there are MySQL gotchas and PostgreSQL gotchas, so you have to know whether the particular glitches are acceptable for you before you decide to use either RDBMS. Understanding the relational algebra, set theory and predicate calculus is essential to understand what the relational model is all about. Lack of this knowledge often leads to confusing tuples with OOP-style objects and other stupidity, so you will save a lot of time learning it first.

Now, the performance. Generally speaking MySQL is faster for a heavy load of simple read-only queries (like Slashdot) while PostgreSQL is faster for complex read-write queries (like a bank). Once you turn on the ACID support in MySQL it is no longer so fast, and it can really crawl because of row or even table (sic!) locking, a mistake avoided for decades by any advanced database. Here is another comparison. See also this recent thread on Slashdot. One of the best comparisons of Oracle, MySQL and PostgreSQL was done by the Computer division of Fermilab (Fermi National Accelerator Laboratory), this is a must-read.

There is a lot to read about it if you need more comarisons, but the general rule of thumb is that if you want lots of very simple read-only and very few read-write queries when the integrity of your data is not critical, you should probably choose MySQL. When you need that (or better) speed but the data is critical and you need ACID transactions which would severly slow down MySQL, try SQLite, the easiest choice there is, especially using Perl where you don't even need to install it (but just like with every other database, there are SQLite gotchas too, you need to be aware of them). If you need full ANSI SQL compatibility, ACID transactions, scalability and your data integrity is important, you should probably choose Oracle or PostgreSQL. There are also licensing issues. Oracle is proprietary. MySQL is GPL so you need to pay if you want to use it in any non-GPL software. PostgreSQL is released under a free-for-all BSD license. SQLite is public domain.

As you can see, there is no one-size-fits-all database. Every one has its strengths and weaknesses. The correct choice is a matter of trade-offs and finding out which database is optimal for your particular niche. Good luck.

Notwithstanding the grammar mistake--I hope editors will have corrected it before I finish writing this comment--it is not "How [Would] Heraclitus ... Design a Programming Language" but rather "What Programming Language Would Heraclitus Design." On the other hand if you are wondering how should you desing and implement a programming language, I would suggest targetting Parrot which makes implementing compilers 1000 times easier than ever before, not to even mention future interoperability and e.g. access to the entire CPAN from the level of your own brand new language, effectively solving the most important problem of new languages: there are no libraries so people don't write anything, and people don't write anything so there are no libraries. Good luck.

The awstats exploit that was used here makes use of poorly written perl that failed to validate user input.

WTF is so hard with validating user input?? Never heard of CPAN?

Of course, had you read the article, you would know that.

Of course, I had so much time during that minute between posting the story and posting my comment, riiight...

I do a lot of that stuff all the time. Perl is your friend. Specifically, perl and Spreadsheet::ParseExcel and Spreadsheet::WriteExcel. The initial parsing of an excel spreadsheet takes a little while, particularly with large sheets, but then you can access the whole sheet on an addressable cell-by-cell basis really quickly. Outputting a new spreadsheet takes, literally, seconds even for large data sets. Wonderful tools for making sense out of Excel stuff.

(A trap for young players I'll mention. I tried to install Spreadsheet::WriteExcel on a Win32/Activestate perl installation a couple of days ago using Activestate's ppm. Turns out that the latest ppd package of WriteExcel doesn't have Win32 support. If you manually browse ppm.activestate.com you'll find that the WriteExcel ppd file a couple of versions old works just fine with win32)

I do a lot of that stuff all the time. Perl is your friend. Specifically, perl and Spreadsheet::ParseExcel and Spreadsheet::WriteExcel. The initial parsing of an excel spreadsheet takes a little while, particularly with large sheets, but then you can access the whole sheet on an addressable cell-by-cell basis really quickly. Outputting a new spreadsheet takes, literally, seconds even for large data sets. Wonderful tools for making sense out of Excel stuff.

(A trap for young players I'll mention. I tried to install Spreadsheet::WriteExcel on a Win32/Activestate perl installation a couple of days ago using Activestate's ppm. Turns out that the latest ppd package of WriteExcel doesn't have Win32 support. If you manually browse ppm.activestate.com you'll find that the WriteExcel ppd file a couple of versions old works just fine with win32)

You wrote "software patents usually don't come with a useful description of how to actually do stuff, which is sad, since software can be documented by the sourcecode and printed."

I'd suggest that patent descriptions might deliberately be vague and unclear. After all, if the patent office isn't going to care, why go to the bother of describing something clearly?

With regards to your second point, I don't know if you've seen the The International Obfuscated C Code Contest or any Perl code, but it's (relatively) easy to write sourcecode that isn't easy to understand, which means that even requireing source code for software patent registrations might not be much use.

Matt

Here is a great leaked picture of the new sub 100$ computer:
Here

If ever there was proof that anything is possible...

http://search.cpan.org/perldoc?PPI

I had to be compatible with .NET SOAP (XML) and I had hard time guessing how to behave to be compatible with the Microsoft SOAP server.

I was using Perl SOAP::Lite, see its section on Microsoft compatibility issues. Still Microsoft conforms to the specification although only the Microsoft way of using standards is correctly recognized. Clearly anti-competitive behavior while still standards compliant - simply perfect.

I had to be compatible with .NET SOAP (XML) and I had hard time guessing how to behave to be compatible with the Microsoft SOAP server.

I was using Perl SOAP::Lite, see its section on Microsoft compatibility issues. Still Microsoft conforms to the specification although only the Microsoft way of using standards is correctly recognized. Clearly anti-competitive behavior while still standards compliant - simply perfect.

Yep. Just use unzip and you'll get several XML files, among them: content.xml is the document itself, meta.xml is the property sheet info, styles.xml is the stylesheet(s) in use when the document was saved.

After that, you can your favorite XML widget, such as the XML::Parser Perl module, to turn it into HTML or other things of your choosing.

Or create an XSLT file and use something like Xalan to
format it on the fly.

Gotta love OOo and those open formats!

It is very easy: http://search.cpan.org/~kwitknr/GD-Barcode-1.15/Ba rcode.pm

especially easy if you know Perl...

It would be rediculously easy to take this, make it a CGI webpage, and publish it for the world to use.

I couldn't agree more about PHP, and how often are the user comments completely wrong, or suggest something that's going to get your site owned.

As for perl documentation its not that hard. On *nix 'man perl' gives a list of man pages and what to look for where. And if you're looking for a specific function you can do 'perldoc -f ' and get a good idea how to use it. Or do perldoc perlfunc (or man perlfunc) to get a complete function list if you aren't sure what to look for. And most pagers let you search the page your viewing.

If you don't have access to a shell there's also http://perldoc.com/ which should have everything that's availiable from a shell. And finally if you need info on specific modules it can be obtained from the shell after installed (at least through CPAN) or you can view the docs on the web by typing in the module name at http://search.cpan.org/

if you still need help there's also http://perlmonks.org/ with lots of people ready to answer your questions :)

And if you do start with OpenInteract, I strongly recommend using the recent beta of OpenInteract 2, which has a much better design and documentation than the first version.

it sounds like it's just a big ol' LSI System

A Perl implimentation of LSI can be found at Building a Vector Space Search Engine in Perl

However, there are at least three problems. First, it doesn't look LSI can answer questions like "Who is the Prime Minister of Canada?"

Second, the approach is patented by Telcordia Technologies.

Third, there are scalability problems with LSI. The author of the Perl article writes:

For all its advantages, LSI also presents some drawbacks. The poor scalability of the singular value decomposition (SVD) algorithm remains an obstacle to indexing very large collections. While techniques have been developed for making incremental updates to a scaled collection, these changes typically cannot exceed a certain threshold without triggering a rebuild [7,8]. These constraints make LSI ill suited to the kinds of large, rapidly changing document collections typically found on the Web.

A further disadvantage to LSI is the difficulty in interpreting the underlying reduced term space [4]. This makes it difficult to select an optimum number of singular values to retain in the SVD for a given collection, or allow domain exert adjustment of relevance values in the reduced space once the SVD has been calculated.

As a result, the author is now pursuing something called Contextual Network Graphs and has written a Perl module that was updated as recently as last August.

Does perl come with spell checking?

If you're in the US, try this site: http://geocoder.us/. It a demo of the perl module Geo::Coder::US, available from the CPAN. Pretty hott.

It uses the Census Bureau's TIGER/Line data, which isn't the most reliable for non-urban areas, but it's public domain.

this year it started on the 28 of December

Dec 28 to Dec 24? Advent travels backward through time this year? That will be a great trick. Maybe we'll be able to track it using Time::Travel or Time::Warp.

this year it started on the 28 of December

Dec 28 to Dec 24? Advent travels backward through time this year? That will be a great trick. Maybe we'll be able to track it using Time::Travel or Time::Warp.

Where he talks about some of the Acme:: modules: Perl 2003 Advent Calendar: Acme::Code::FreedomFighter.

Then, you can go explore the rest of the Acme namespace.

• odbc_connect
• ora_connect
• mysql_connect
• pg_connect

I get sick of the 'standard' backlash every time a Perl article is posted. Why do people have such a problem with Perl? It's an excellent, high-level general purpose programming language with a huge range of extension modules available. I have personally used Perl for many projects, as do TicketMaster, ValueClick, Morgan Stanley and Ryanair and I've also learnt a lot about software engineering and computing through Perl.

Of course you are right. But let's not forget that there are also lots of completely useless Perl projects as well.

Yes, it does include a lot of symbols, but there is payback to learning them, and really most programs won't use much beyond $ % # () [] {}. Unlike some languages, Perl is not what I would describe as a 'bondage' language. If you want to program sloppy, you can program sloppy. That's fine by Perl. And this generousity is what gives Perl its bad reputation. This is funny since I and most knowledgeable Perl programmers can write perfectly clear and maintainable code. The way we do this is no secret--it's just by commenting appropriately, using meaningful identifier names and following the Perl style guidelines.

People can mock Perl all they like, but it is still a widely used powerful programming language and I am more productive in it than any other language. As a parting comment, a Cisco employee once told me (off the record of course!) that "Cisco would fall apart without Perl".

Yes, it does include a lot of symbols, but there is payback to learning them, and really most programs won't use much beyond $ % # () [] {}. Unlike some languages, Perl is not what I would describe as a 'bondage' language. If you want to program sloppy, you can program sloppy. That's fine by Perl. And this generousity is what gives Perl its bad reputation. This is funny since I and most knowledgeable Perl programmers can write perfectly clear and maintainable code. The way we do this is no secret--it's just by commenting appropriately, using meaningful identifier names and following the Perl style guidelines.

People can mock Perl all they like, but it is still a widely used powerful programming language and I am more productive in it than any other language. As a parting comment, a Cisco employee once told me (off the record of course!) that "Cisco would fall apart without Perl".

Yes, you did misinterpret the message. Eric Raymond was a former Perl programmer, and is now a Python programmer. He was saying that Python's native-code-binding facility is superior than Perl's XS, and it would benefit Perl to adopt it. He mentions that Python benefitted from adopting Perl's regex syntax. Nowhere does he say or imply it was "grudgingly" done.

By the way, not long after he wrote that, Perl coders started using the Inline:: modules like Inline::C instead of XS, which is very easy to use. I do not know if this was an adoption of Python's technique, but I don't think so.

It is not PERL, it is Perl.
FAQ answer to this

1) Generate fake credit card numbers that pass as "valid"

Easy: Business::CreditCard - Validate/generate credit card checksums/names.

If my calculations are correct then when you run another Debian emulated on top of the Mac OS X Panther, which itself runs under PearPC on the underlying Debian, then when you run apt-get dist-upgrade there is already a new stable version of Debian released.

Oww. That hurt to think about.

Oh, really? Than you should think about this:

The best compliment I've gotten for CPR is when my ActiveState coworker Adam Turoff said, "I feel like my head has just been wrapped around a brick". I hope this next example makes you feel that way too:

#!/usr/bin/cpr
int main(void) {
CPR_eval("use Inline (C => q{
char* greet() {
return \"Hello world\";
}
})");
printf("%s, I'm running under Perl version %s\n",
CPR_eval("&greet"),
CPR_eval("use Config; $Config{version}"));
return 0;
}

Running this program prints:

Hello world, I'm running under Perl version 5.6.0

Using the eval() call this CPR program calls Perl and tells it to use Inline C to add a new function, which the CPR program subsequently calls. I think I have a headache myself.

(from Pathologically Polluting Perl by Brian Ingerson)

Lameness filter encountered. Post aborted! Reason: Please use fewer 'junk' characters. Hopefully my explanation will dilute those "junk characters" and will let me post this comment. It's interesting that this lame filter stops me from quoting programs but doesn't stop anyone from posting full-screen ASCII-art swastikas and pornography. But anyway...

Thanks to the Inline module, it is possible to include fragments of C code in Perl programs. You can write part of your Perl program in C (for example one speed-critical subroutine) and it is automatically compiled to native binary machine code and linked as a shared object (see this comment of mine and read the paragraph starting from "Actually, inlining other languages..."). CPR stands for "C Perl Run." From the description:

Is it C? Is it Perl? It's neither, it's both. It's CPR! CPR (C Perl Run) is a "new language" that looks like C. You don't need to compile it. You just run it, much like Perl. As an added bonus, you'll get access to the full internals of Perl via the CPR API. The idea is that you just put a CPR hashbang at the top of your C program and run it like a script. The CPR interpreter will run your C code under Perl.

In other words, CPR program is a C program which is run by Perl, just as if it was a C code inlined in a Perl program.

Now, in this case, the C program I quoted (which is itself run by Perl), includes a Perl code inlined in C by CPR_eval(). What is inside that inlined Perl code is an inlined C code (use Inline...) which is a C function greet() that returns a C pointer to C string "Hello world". The next part of the original (outermost) C program is a C printf() function printing two C strings. Those C strings, arguments to printf(), are returned by two invocations of CPR_eval(), both of which inline Perl code. The second one just returns Perl interpreter version, but the first one is more interesting. The first CPR_eval() returns a C string to printf() which is converted from a Perl string returned by the Perl code inlined in that CPR_eval(), which is a call to Perl greet() subroutine which was defined earlier by the C function inlined in the Perl code inlined in the C code by the first CPR_eval() invocation. It all happen inside a C main() fu

If my calculations are correct then when you run another Debian emulated on top of the Mac OS X Panther, which itself runs under PearPC on the underlying Debian, then when you run apt-get dist-upgrade there is already a new stable version of Debian released.

Oww. That hurt to think about.

Oh, really? Than you should think about this:

The best compliment I've gotten for CPR is when my ActiveState coworker Adam Turoff said, "I feel like my head has just been wrapped around a brick". I hope this next example makes you feel that way too:

#!/usr/bin/cpr
int main(void) {
CPR_eval("use Inline (C => q{
char* greet() {
return \"Hello world\";
}
})");
printf("%s, I'm running under Perl version %s\n",
CPR_eval("&greet"),
CPR_eval("use Config; $Config{version}"));
return 0;
}

Running this program prints:

Hello world, I'm running under Perl version 5.6.0

Using the eval() call this CPR program calls Perl and tells it to use Inline C to add a new function, which the CPR program subsequently calls. I think I have a headache myself.

(from Pathologically Polluting Perl by Brian Ingerson)

Lameness filter encountered. Post aborted! Reason: Please use fewer 'junk' characters. Hopefully my explanation will dilute those "junk characters" and will let me post this comment. It's interesting that this lame filter stops me from quoting programs but doesn't stop anyone from posting full-screen ASCII-art swastikas and pornography. But anyway...

Thanks to the Inline module, it is possible to include fragments of C code in Perl programs. You can write part of your Perl program in C (for example one speed-critical subroutine) and it is automatically compiled to native binary machine code and linked as a shared object (see this comment of mine and read the paragraph starting from "Actually, inlining other languages..."). CPR stands for "C Perl Run." From the description:

Is it C? Is it Perl? It's neither, it's both. It's CPR! CPR (C Perl Run) is a "new language" that looks like C. You don't need to compile it. You just run it, much like Perl. As an added bonus, you'll get access to the full internals of Perl via the CPR API. The idea is that you just put a CPR hashbang at the top of your C program and run it like a script. The CPR interpreter will run your C code under Perl.

In other words, CPR program is a C program which is run by Perl, just as if it was a C code inlined in a Perl program.

Now, in this case, the C program I quoted (which is itself run by Perl), includes a Perl code inlined in C by CPR_eval(). What is inside that inlined Perl code is an inlined C code (use Inline...) which is a C function greet() that returns a C pointer to C string "Hello world". The next part of the original (outermost) C program is a C printf() function printing two C strings. Those C strings, arguments to printf(), are returned by two invocations of CPR_eval(), both of which inline Perl code. The second one just returns Perl interpreter version, but the first one is more interesting. The first CPR_eval() returns a C string to printf() which is converted from a Perl string returned by the Perl code inlined in that CPR_eval(), which is a call to Perl greet() subroutine which was defined earlier by the C function inlined in the Perl code inlined in the C code by the first CPR_eval() invocation. It all happen inside a C main() fu

I got interested in Hold'Em several months ago. My natural inclination was to read books && write code. The result was this:

http://Search.CPAN.Org/~pip/Games-Cards-Poker-1.2. 46QD4ax/Poker.pm

I started calculating situational odds... exhausting some of the combinatorics. I wanted to do this as Free Software so that other GNU/Linux geeks could be helped to calc odds && make bots too. I figured I'd be able to make a simple CGI or ptk interface to the data which would be natural to use while playing online.

But then I actually broke the ice && started playing. I played against friends a bunch of times && sat down at a nearby casino table once. I quickly realized that it's fscking boring to me. Even if I know a lot already && have an aptitude to learn how to become great... all the time I'd have to spend to weather the storms... all the time I'd have to just sit there "playing" would not be fun for me. I'd rather play PS2 or code or read.

So, in my case, the computational challenge was fun && I hope my code can benefit others (let me know if you'd like additions to Poker.pm or if you'd like my CGI or ptk code... as I'd be glad to share it under GPL) but the time investment to actually make money doesn't seem worth it since I don't like the activity. I don't get paid all that much but I work on a job I love. Even if I could make a bit more playing Hold'Em, so far, I'd rather not.

On another interesting note: There's been an emergent topic in this thread which I find perpetually interesting. Are programmers (or middle-class people in general) generally smarter than others, the majority, the masses, the lower-class? It seems to me that we know we are. We read more, study more, learn more, analyze, criticize, calculate, etc. because we constantly need to solve new && different problems. We're more on our toes... we're more savvy... progressive. We often identify with the intelligent Nipponese (through video games, anime, gadgets, sport bikes, sushi, manga, etc.) more than the bumbling drunken Mtv Madden war-minded pro-violence repressed-sex consumer sheeple attitude that is so prevalent around us.

Maybe it is haughty. Maybe our responsibility is to our country && the world. We should strive to educate && illuminate our fellow United Statesians (apologies to all non-USians but I suffer as /. does from US-centricity because it is where I live && what I primarily know... shit && because we constantly reach all over && impact the whole rest of the world more than any other country). Some of our "intelligence" is of course rote knowledge like C++ object syntax or underlying problem-solving principles like design patterns or search/sort algorithms but people with a propensity for such things spend time cultivating those skills at the expense of others. So while we know how to map sometimes devastatingly enormous && complex spaghetti code into our minds completely, others are social virtuosos. They can be much better managers or salespeople etc. because they are good at appearing to be your friend. They're not so systematic && analytical... they have intuition about feelings, emotions, underlying motivations... they can encourage you to work hard for something you hardly care about or believe in... maybe they believe themselves if not just for a bigger paycheck. They are (generally) more adept than coders at human interaction / manipulation. Salespeople can convince customers that they need to buy products they hardly need for way more than they're worth with some crazy high interest loan that more than doubles the end cost.

So who's smarter could be a matter of perspective. Geeks with few social skills might not relate well to each other or society because their affinity is for powerful &&/or optimized &&/or clever

If a PHP or Perl app could be emebedded into a browser, I'd have to change my pants.

This is pretty close for some uses, and with some more development it could really be something:

http://search.cpan.org/search?query=XUL%3A%3ANode& mode=module

Do try out the examples! :)

Two things I'd need/like and that doesn't seem to be there, although I haven't had time to investigate yet, is the possibility to run this via an existing web server instead, and the editor widget.

I have no idea why has your post been moderated as Troll. Those are very good questions. There will be many ways to interoperate on many levels. I'll start from the things you are asking about, i.e. mixing languages in the same file, and then I'll talk about what I think will be even more important. First of all, in Perl 6, eval() will take an optional argument which will be the name of the language used to compile the string:

#!/usr/bin/perl
# Perl 6 program
eval "Ruby code", "ruby"; # Ruby code as a quoted string
eval <<ENDPY, "python"; # Python code as a here-document
# Python
# code
ENDPY
# Perl 6 code again

This is the most verbose syntax and something similar will probably be added to other languages, even those with no built-in eval(), by using some simple module or library in the worst case. Every language compiler will be available on the Parrot level, so it won't be an issue.

Actually, inlining other languages code is already possible today in Perl 5, using the Inline modules:

"The Inline module allows you to put source code from other programming languages directly 'inline' in a Perl script or module. The code is automatically compiled as needed, and then loaded for immediate access from Perl."

For example I just ran this Perl program:

#!/usr/bin/perl
use Inline C;
print "9 + 16 = ", add(9, 16), "\n";
print "9 - 16 = ", subtract(9, 16), "\n";
__END__
__C__
int add(int x, int y) {
return x + y;
}
int subtract(int x, int y) {
return x - y;
}

It printed: "9 + 16 = 25" and "9 - 16 = -7" but 25 and -7 were computed by C functions. The first time I ran it, it took longer because the C code had to be compiled, but every next time the already compiled shared object is used and it starts instantly. When the C code changes, the module recompiles the shared object automatically and saves the new version. This is a simple example which may seem useless, but you might for example write the speed critical parts of your Perl program in C to speed it up, etc. without the need to learn the XS language normally used to create an extension interface between Perl and C.

Using other languages in Perl 5, though, especially other than C, is probably not very elegant under the hood. Also, you cannot pass live objects back and forth and axpect them to behave normally, as far as I know. Perl 5 and Python both use their own virtual machines, with different bytecode and different behaviour, like garbage collection, threading etc. When Perl 6, Perl 5, Python and Ruby are running on Parrot, they will all get compiled to the same bytecode, with the same function calling conventions, the same exception handling, they will run on the same VM, with the same threading, garbage collection, etc. only with different data semantics, because for example Perl strings in numeric context are converted to numbers, Perl 6 will have things like 0 with true boolean value, etc.

Going back to inlining other languages in Perl 6 programs, in addition to eval(), thanks to powerful macros, someone will easily write one which would let you write:

#!/usr/bin/perl
# Perl 6
use Python;
# Python
no Python;
# Perl 6

or POD-style:

#!/usr/bin/perl
# Perl 6
=begin Python
# Python
=end Python
# Perl 6

or an XML-style, or some fancy bracketing, or indeed whatever syntax you'd like. But probably more important than mixing languages in the same file, would be the ability to use classes and objects from other languages. For example, you will be able to use Perl DBI module from CPAN in a Python program, using probably something like this:

dbh = Per

Can I get any advice? Is Ruby really "more powerful than Perl and more object oriented than Python" - is this what I'm looking for, or should I put it off and learn Python first?

No, it is not more powerful than Perl. But than again, nothing is. The points is not what is more powerful per se, but rather which is more powerful in your hands and which one best fits your own brain. At this point it is extremely important to mention Parrot: "The amazing project [...] to really unite Perl and Python one day (not to mention Tcl, Scheme, Forth and Ruby, to name just a few)."

Perl, Python and Ruby, while not the only ones, are certainly the most important languages for the Parrot development. Parrot will not be considered ready until all of them are fully supported, and at this point Parrot will be their main target Virtual Machine, running each of them and allowing them to interoperate. At this point it won't matter which of those languages you personally use, because whatever you choose you will still have access to all of the libraries and module, class and object, of each of them.

Few years ago I will tell you: "go for Perl because of CPAN." Now my advice woule be: "go for whatever you please, for in few years it won't really matter. We will be able to work on the same project, write the same application. I will write my part in Perl 6, you will write yours in Ruby, someone will write in Python and another one in Scheme. We will all subclass our classes, invoke our methods, use our objects, and we will produce a single, monolithic Parrot application anyway."

Just imagine picking up some fresh, young and cutting-edge language designed weeks ago--or even designing your own language--and having every module from CPAN available at once, working just fine using your new language syntax. This is the future Perl, Python and Ruby. Interoperation instead of competition.

It's true that OOo emulates some of the usability bugs of MS Office. Using the chart component of OOo Calc can be rather painful, for example: It has three (or more?) different modes of displaying a chart, and different menu options become available depending on which mode you're in; switching between them is not at all intuitive. I remember having had similar issues with Excel in the past. Still I found Calc's charts capability vastly superior to Gnumeric and KSpread (no offense to these projects).

The main beef people have with OOo is its monolithic nature, which makes it slow to load and heavy to download. I haven't found AbiWord usable enough to recommend it as a small alternative. Perhaps one day there will be a Firefox-like offspring of the OOo project. But OOo's feature set is certainly on par with MS Office. There's no valid reason for governments to subsidize Microsoft - if anything, they should subsidize open source development.

Sounds about right, so in the spirit of imagining user requirements, I'll simply describe what I have done: I've got a P3 450 MHz running XP Pro, with 300 GB of hard drive space. I'm using the optical digital output (SPDIF) from my soundcard driving a $9000 stereo system, so I don't want to fool with any kind of lossy compression, so I use FLAC. I use Winamp as the player, since there is a FLAC plug-in for Winamp, and a webserver plug-in. The webserver plugin allows you to send http get requests to Winamp to send commands to it. Then I have a perl script that scans my directory structure (spanning multiple logical hard drives) for all FLAC (and WAV, and mp3), and generates an HTML file that has a (per album) table of contents, which is hyperlinked into the webpage body. In the body, you can play an album, any one song, or "create a playlist on the fly" by simply checking checkboxes (per song). This webpage is served by an Apache server, which is also running a Perl CGI script, which receives the commands from the webpage, and dispatches the appropriate commands to the Winamp webserver plugin. Additionally, I can control my pre-pro from the same webpage, by using Win32SerialPort for Perl, and the pre-pro's serial port. Lastly, I have a set of scripts that: (1) Convert WAV files to FLAC (for use right after ripping a CD) (2) Convert WAV/FLAC files to mp3, and copy them to another PC, where I maintain my iPod directory. (3) Copy these mp3 to my PC at work. Now I only need to use Apple's COM interface to automatically update my iTunes library so I don't have to go into iTunes and tell it to add a new folder! Almost forgot to mention, the main reason I think the web interface is such a good idea, is because: (1) I can control it from any computer on the network, and (2) Using either an RF keyboard, and/or a standard universal remote and Girder, I can have full control of the stereo from my couch. For now, I have a 17" monitor in my stereo rack (yeah, it ain't pretty), and use PHP commands to make the web page text large on that monitor. Long term, I plan to have a 50-60" LCD or DLP projection TV, which will be much nicer.

Does it have to be a C code? In my opinion C is not nearly obfuscatable enough. What about BF or Unlambda? Or, better yet, Lingua Romana Perligata?

how about Brainfuck

Well, yes. Certainly. That was actually my first example. I only used the euphemism "BF" instead of this vulgar profanity, so this misunderstanding is, well, understandable.

I have finally finished my code example! It is written in Perl instead of C so I won't send it to the contest, but I think it will nicely demonstrate many very important aspects of code obfuscation and subtle errors in the program control flow which can unexpectedly change at run time. I'm sorry that it took so long, it was a lot of work, mostly testing to make it portable, but I think it was worth it. Here it is:

#!/usr/bin/perl
use Acme::Bleach;

(I hope Slashdot will not mess with the whitespace because it is significant just like in Python -- see: perldoc Acme::Bleach by Damian Conway and Proletext by Brad Templeton.)

Comments welcome.

C code that appears correct but does the wrong thing when counting votes.

Does it have to be a C code? In my opinion C is not nearly obfuscatable enough. What about BF or Unlambda? Or, better yet, Lingua Romana Perligata? Now when I'm thinking about it, I think PASM might be perfect for such a task, if only-- I know! Acme DWIM or Bleach compiled directly into PASM! With JIT!! Dear God, that would be so cool!!! But wait, they want C code, right... Wait a minute, Perl is written in C! So is Parrot! And they can be embedded in a C program! Sweet Heavens! What an idea!!!1 Gotta go.

C code that appears correct but does the wrong thing when counting votes.

Does it have to be a C code? In my opinion C is not nearly obfuscatable enough. What about BF or Unlambda? Or, better yet, Lingua Romana Perligata? Now when I'm thinking about it, I think PASM might be perfect for such a task, if only-- I know! Acme DWIM or Bleach compiled directly into PASM! With JIT!! Dear God, that would be so cool!!! But wait, they want C code, right... Wait a minute, Perl is written in C! So is Parrot! And they can be embedded in a C program! Sweet Heavens! What an idea!!!1 Gotta go.

C code that appears correct but does the wrong thing when counting votes.

Does it have to be a C code? In my opinion C is not nearly obfuscatable enough. What about BF or Unlambda? Or, better yet, Lingua Romana Perligata? Now when I'm thinking about it, I think PASM might be perfect for such a task, if only-- I know! Acme DWIM or Bleach compiled directly into PASM! With JIT!! Dear God, that would be so cool!!! But wait, they want C code, right... Wait a minute, Perl is written in C! So is Parrot! And they can be embedded in a C program! Sweet Heavens! What an idea!!!1 Gotta go.

Do you want to call modules you wrote from a python program? Or do you want to call python modules from perl. For the latter look no farther than cpan

For the former, first check out the python package index , which is the equivelent of CPAN to see if someone else has created a relevant package. If not, creating a python module from C code from python is easy . As far as calling perl modules from python, that is one of the things Parrot is intended to do, so your savior will come with the apoclypse.

Examples please? I couldn't think of any off-hand.

Although, all those Inline::* modules on CPAN is allowing you to do just that, so apparently people find it at the very least amusing. ;-)

Although VBScript isn't a likely port... BASIC has been ported to Parrot. There's even a working Parrot-BASIC CGI script.

The Perl equivalent is Class::DBI. This is quite a good module for working with databases, as it can save you from writing a lot of code. This article discusses the power of Class::DBI combined with the Template Toolkit, the best pure-MVC templating system there is. Maypole is a system built around these two modules that lets you create a complete Web-based database interface in as little as ten lines of code! Another Maypole article is here.

The real power of snmp is what you can achieve through scripting it - queries and updates etc. That becomes nigh-on impossible with this WS-Management craziness.

You can call a method on a webservice with one line of perl. Nuff said.

var db = 'Apache::DBI::db=HASH(0x855aaf8)';
if(!db)top.par ent.document.location.href='/sei/index.htm';