Slashdot Mirror

Intercal has nothing on Brainfuck. Brainfuck makes every other spoof programming language look like a joke.

Not sure whether that was intentionally humourous or not, but well done, nonetheless.

But seriously[*] kids, nothing holds a candle to ACME. All the programming foolishness you'll ever need, implemented in glorious Perl!

--------

[*] Whatever....

> I'm interested to find out how to clean up "incorrect" Geolocation info too.

You can't.

I wrote IP::Country, the library used for country detection of relays within SpamAssassin. There is no manual tweaking of the country codes, I simply take the raw country data from the Regional Internet Registries (ARIN, RIPE, APNIC, LACNIC, AFRINIC) and encode them into a small, portable database.

That is also how all the other IP geolocation libraries work. If you started out from the premise that you'd accept manual changes to the database, it would produce more inaccuracies in the long run that simply following the WHOIS changes.

There is another way, which no one is using. Contraint-based geolocation pings the IP address from several known locations to estimate the location. There are academic papers saying it's more accurate than the WHOIS data, but it's never going to work on a webserver because it's doesn't produce a fast enough answer.

If you're interested in how the country data changes over time, check out the CVS of my data.

The only way to clear up a mistake in my country code is to correct the country code with the Regional Internet Registry. You won't be able to do that unless you own the block.

Everyone has already noted that this only tracks hits, not searches. I'd like to suggest a few code improvements.

At a high level, use RRD (http://search.cpan.org/~nicolaw/RRD-Simple-1.43/lib/RRD/Simple.pm) for the underlying database. RRD is used by MRTG to track time-varying data over multiple time scales, keeping details for recent data and summaries for historical data. RRD also comes with its own plotting module, although you could keep using Gnuplot if you wish.

In the code itself, there are places where there are "elsif" clauses without an "else" clause. One seems alright, but should have a null "else" so document that fact. The other, however, is testing keywords from the config file, and should flag any that are unrecognized.

Finally (and this is probably nit-picking), instead of this:
    return unless EXPR;
    do something;
    return;
I'd use this:
    if EXPR {
        do something;
    }
    return;

Nice idea, but I like the SQL interface better.

One nice thing you can definitely say about Java as a language is that code that is poorly written in Java is easier to read than code that is poorly written in Python or PERL.

That's a silly comparison. No one writes code in PERL. It's a joke language.

I agree, community is vital to the success of a programming language. Some languages, C for instance, have uninviting but huge communities. You won't be hard pressed to find someone who knows the answer to a run of the mill question in C. You may have some trouble getting an answer other than RTFM, though.

However, a friendly, helpful, and well-established community is not a sufficient condition for the success of a language. Take Perl as an example. Perl Monks is one of the most welcoming and helpful communities I've ever seen on the internet, period. Literally nothing compares regardless of field. And furthermore, they'll answer the full gamut of questions, ranging from utter newbie to relatively advanced functional programming and beyond.

Let's not forget CPAN, which is probably the largest and best organised collection of packages and libraries for any programming language on the internet. Yes, there is a little noise you have to wade through, but the signal to noise ratio is unbelievably high. If you want to do something in Perl, it's likely that you can find a module on CPAN that will at least give you a base of code to work with, if not a completely working and tested solution.

You'll note that despite those two great features, Perl continues to lose popularity, mostly to Python. It's probably due to the fact that, even though Perl is pretty easy to get started with, as you note Python is down right trivial. People call it pseudocode that you run because it's so damn simple and easy to get going, which is probably one of its greatest strengths. Perl has been around longer, probably has a larger and friendlier community, yet the outright ease with which one can program in Python trumps those other, greater (in my opinion) strengths of Perl.

It's sad to see such a great language get knocked all the time due to a bad reputation (which it certainly deserved--five to ten years ago). Unfortunately, a combination of a bad rep and an easier to use, more popular language is starting to make it look like Perl will soon be relegated to a relative niche, at least in the eyes of the public.

On a project I was on, I needed to parse 50+ COBOL copybooks in .NET so that we could use those data definitions to whittle down a 600MB flat file full of nightly data for a data warehouse.

I tried ANTLR, and I wound up abandoning it. I wanted ANTLR to work - I really thought it seemed to be the best and most mature solution, but the documentation is ABYSMAL. And if you want to use .NET with it instead of Java, there's a reserved circle in hell for that.

I'm sure if I'd had proper documentation, I could have managed it. I have a CS degree and took a 400 level automata class as part of my curriculum, so I'm no feather weight on this topic. Heck, I've even used this in a past life. But, I still was at a loss as to how to even begin with ANTLR and C#.

I found Gold Parser, and I was done with 151 commented lines in my grammar file, 148 lines of generated C# code in a constants file, and less than 500 lines of business logic to actually deal with the parsed copybook to do what we needed to do with it. The whole development effort was mere days, and let me quickly get out of the weeds and back to solving the real business problem.

Recently, I saw this ANTLR reference discarded on a shelf in Half Price Books, and just had to pick it up. I thought, maybe this would have gotten me there. Alas, the book is not even close to a reasonable reference. Moving from tokenizers and Regular Expressions to full-fledged CFGs is not a layman's topic, but there's not much help to be gleaned from the arcane drivel that comes from Mr. Parr's book on his already overly complicated application. If you're interested in theory and wallowing in the mire of acedemia, then this is the book for you. But, if you have a working understanding of the topic and just want to get the blasted tool to work, the best advice I have is to stay far, far away. At least, that is, until someone other than Parr himself sets forth a reasonable guide to this ANTLR'ed beast.

I found this to be much the same with Parr's StringTemplate project. After trying to figure it out from the limited documentation, I found it less painful to just dredge up NVelocity from its hidden location at Castle Project, fish for the necessary dlls, throw away the rind (who uses Castle anyway???) and happily went about my merry way.

You probably have an older version of the JSON module. Version 1.xx doesn't have "from_json", but "jsonToObj" seems to be equivalent. http://search.cpan.org/~makamaka/JSON-2.09/lib/JSON.pm#INCOMPATIBLE_CHANGES_TO_OLD_VERSION">http://search.cpan.org/~makamaka/JSON-2.09/lib/JSON.pm#INCOMPATIBLE_CHANGES_TO_OLD_VERSION

I often prefer using Perl for such easy tasks:

Text::CSV

will handle a CSV file for you quite well (keep in mind that separators need to be distinct from the entered text). It can associate arrays and hashes to the lines.

And even better, if you later feel like your Text::CSV handling is not working well enough, you can switch to or simply add code using:

DBD::CSV

which internally uses Text::CSV anyway. This way you can run SQL queries on your previously created CSV files.

References:
http://search.cpan.org/search?mode=dist&query=Text%3A%3ACSV
http://search.cpan.org/search?mode=dist&query=%3ADBD%3A%3ACSV

I often prefer using Perl for such easy tasks:

Text::CSV

will handle a CSV file for you quite well (keep in mind that separators need to be distinct from the entered text). It can associate arrays and hashes to the lines.

And even better, if you later feel like your Text::CSV handling is not working well enough, you can switch to or simply add code using:

DBD::CSV

which internally uses Text::CSV anyway. This way you can run SQL queries on your previously created CSV files.

References:
http://search.cpan.org/search?mode=dist&query=Text%3A%3ACSV
http://search.cpan.org/search?mode=dist&query=%3ADBD%3A%3ACSV

The question seems slightly misguided, and the answers suggesting sqlite3 seem very good. However, if you want a literal answer, I would think that Python's csv module does what the poster requested: http://docs.python.org/lib/csv-examples.html. Well, if you're inclined in a different way, you could use Text:CSV: http://www.cpan.org/modules/by-module/Text/Text-CSV-0.01.readme

Use perl with a tied hash like BerkeleyDB http://search.cpan.org/~pmqs/BerkeleyDB-0.34/

Easy, fast, simple.

For Perl, Perl::Critic is excellent:

I don't have a lot to add, except that if you program Perl and don't use it, you shall spend more time on debugging.

Ahh, good times. I used to run the DNS for barnyard.co.uk on that :-)

Why? Because I could, and it was preferable to running BIND. Come to think of it, it still is preferable to running BIND. I think I shall port it to my Z80 emulator!

... there are so many ways to write something that invariably people will use what they are comfortable with but necessarily what someone else would use, so you get a lot of different coding styles which make it very hard to debug and support.

I've found the same in any language, when you take into account maintenance concerns regarding naming conventions, indentation and bracing styles, the length of functions and methods and classes and modules, the presence or absence of design patterns, custom libraries, and domain knowledge. You can look up syntax in the manual.

If you want coding standards for Perl (and if you want to produce maintainable code in any language, agree on some sort of coding standards within your team), start with Perl Best Practices and use the Perl::Critic distribution to identify places for improvement. Then, of course, practice all of the other important development practices such as comprehensive testing, refactoring, code review, and the like.

After that, if you still can't produce maintainable Perl code, I'll buy you a cookie.

PERL isn't even in the list, you nut.

Comprehensive Perl Archive Network

2008-03-18 online since 1995-10-26
4236 MB 236 mirrors
6503 authors 13220 modules

Street names in the US are assigned by the government and the government can't own a copyright in the US. All most all of those maps have errors and they have a lot of the same errors because they are based on the TIGER, Topologically Integrated Geographic Encoding and Referencing system, database. The TIGER database is maintained by the U.S. Census and while they are huge, you can have a lot of fun with them especially when you mix in the Perl module Geo::Coder::US and GMT, Generic Mapping Tool. The TIGER is a database of any known and and a huge number of interpolated data points, for example my house is listed as a known point with it's "official" latitude and longitude, two blocks down is another known point and every house in between is estimated. One thing you quickly notice when playing with the database is that roads often have multiple "official" name, Roads may "officialy" exist but not physically exists and roads may physically exist with out "officially" existing. Roads can even meander and move, especially dirt fire-roads and trails in the woods.

The concept is called templating and used to be called 'Server Side Includes' (somewhere around 1997 or so ... ). ASP, JSP and PHP are originally SSI languages / templating languages.
And if you want to use templating for your web developement - which is discussion worthy in itself - anything other that TAL (Pe(rl)-TAL, PHP-TAL or 'original' TAL is completely pointless, because the above mentioned languages are nothing but templating solutions in themselves. There is no point bolting another layer of that on top of them. Which is why I strongly dislike Smarty and it's ilk.

Oh, and I highly doubt that ASP has anything as neat and usefull as TAL. Do check out the OSS solutions, they're regarded as technology leaders in the field for a reason, which is one reason ASP & Co. are treated with suspicion.

Just because you can't use tools made for processing text in Unix line-based format, doesn't mean there aren't tools for this purpose. You can even find tools inspired on awk for XML processing, like xmlgawk (also here).

However...

I agree with you that XML is not the answer for everything. For instance, I just hate XML configuration files, exactly because you can't reliably grep, sed, awk, ex, them. Editing XML with vi is not the nicest task either. For config files I usually like INI-style files, for which there are modules in Python and Perl, and you can easily get around with simple shell tools when you just need a dirty hack. A config file usually has a simple enough structure to allow you to specify anything you need in the constraints of INI files (if it doesn't, you should probably rethink your config, it's probably bloated!).

For other tasks such as tabular data, CSV or just plain text delimited by tabs or ":" (think /etc/passwd) are more suited than XML, exactly for the ability to use simple universal tools (grep, sed, awk) on the data. It's even easier to visually inspect a table if it's in CSV or tab-delimited than it is to inspect an XML file and try to see through the tag soup.

Your comment about logfiles is right on the spot! Log files are just made to be grepped. Anything that doesn't write all relevant information of an action on one line, at the time the action happened, really defeats the purpose of logging.

Hmm...so are you advocating writing GUI apps completely in Tcl, or writing the app in some other language, but doing the GUI parts in Tk? From what I've heard, Tcl itself is a reasonably nice language. But personally I don't want to learn a whole new language just so I can use a particular GUI toolkit, and if I'm going to write my app in a scripting language I'd prefer to use Perl or Python, due to their excellent, comprehensive libraries.

I've done a Perl/Tk GUI app, and my experience was decidedly a mixed bag. On the one hand, I found it very pleasant and efficient to code to the Perl/Tk interface. On the other hand, I ran into some major issues with code quality and the fact that nobody is actively maintaining the code base. If you look through the Perl/Tk source code, you see page after page of C that handles pointers as if it was still 1978. This led to one major snafu that made me decide never to touch Perl/Tk again: there was a null-pointer bug that interacted badly with a GTK release that came out ca. 2005, causing Perl/Tk applications to crash randomly. I submitted a patch, but it took ages for it to be applied, and during that time all Perl/Tk apps were crashing frequently on, e.g., all the recent releases of Ubuntu.

A fine example that is more than just elegant code is given at http://search.cpan.org/~jnagra/Acme-Smirch-0.91/Smirch.pm

Now a lay-person seeing this would be impressed by the art of the code, whereas the programs of the article would only impress with the art of their output. Compare "Programming As Art" with "Programming Art".

Perl scripts may not be portable because they use modules that are not installed everywhere.

Then simply bundle the modules with your program. Not always a universal solution, but we use it a lot to distribute perl applications around our site.

3D ray tracing using Perl... why not?

Apparently you aren't a user of PDL. I'm toying around with some real-time CFD and their visualizations, all in perl.

Basically, if your writing tight loops, your not thinking at the correct level, and ultimately, programming is a specialized form of thinking.

Both languages have lots of idiots writing bad code in them. Perl is an extremely flexible and well-designed language, upon which many good modern layers of language meta-enhancement (have you looked at Moose - http://search.cpan.org/dist/Moose ?) have been built. PHP is an atrociously-designed language that only someone who loves things like HTML and Visual Basic could love.

Perl is the duct tape of the internet that real working people hold big things together with on a daily basis, PHP is the elmer's glue some 12 year old is trying to sniff to get high (in vain, because it's the new kind that you can't get high off of anyways).

Of course PHP's popular, it's very easy to deploy it and start writing code in it with zero skills (and to their honest credit, packaged full-blown PHP applications are generally easier to deploy than the equivalent in Perl), but that doesn't mean it's a good language to architect things in.

1. D'uh. I wouldn't use Ruby or PHP for "ray-tracing ... 3-D computer graphics", either
2. It seems like he's trying to reach for something negative, to the point of contradicting the same point that he said was positive. Seriously, if you're writing a shell script, are you really worried about porting it or its performance? All of the shell scripts I've written for our servers stay on our servers and are mostly cronjobs, where I don't care about how much memory or CPU time it takes.
3. Gee, I guess all my web work over the last 7 years in Perl is a waste and doesn't do anything good? HTML inlined in code? That's so 90's ... hasn't he heard of Perl's MVC frameworks? CGI::Application, Catalyst, Template Toolkit, HTML::Template, etc. ?
4. Most Perl developers opt for Best Practices these days, rendering his point #4 obsolete.

I use perl -MIO::All -e 'io(":80")->fork->accept->(sub { $_[0] < io(-x $1 ? "./$1 |" : $1) if /^GET \/(.*) / })' as my webserver you insensitive clod!

(I ripped it from the IO::All documentation. That's gotta be secure, right?)

That's true. I just brought up CGI.pm because it's the one that ships with Perl, and thus the one people are most likely to use. In fact, CGI.pm's old cgi_docs document (deprecated after CGI.pm 3.06) even mentions CGI::Base, CGI::Form, CGI::MiniSrv, CGI::Request and CGI::URI::URL by name.

So he's saying PERL is easy to read?

You're probably thinking of the web programming language PERL, which is basically a joke. This article is about Perl.

Perl is neutral on that spectrum.

No it is not.

Perl has far more tools to support making clean MVC web separation stuff than ruby. The issue is that what represents "good" or "clean" code is domain specific. All the things are showed you are things that are good for the specific problem of document templating for the web. I'd be willing to say that Perl's flexibility lets you code in pretty much any domain cleanly...if you set up your environment to facilitate that.

Perl is neutral on that spectrum.

No it is not.

Perl has far more tools to support making clean MVC web separation stuff than ruby. The issue is that what represents "good" or "clean" code is domain specific. All the things are showed you are things that are good for the specific problem of document templating for the web. I'd be willing to say that Perl's flexibility lets you code in pretty much any domain cleanly...if you set up your environment to facilitate that.

Perl is neutral on that spectrum.

No it is not.

Perl has far more tools to support making clean MVC web separation stuff than ruby. The issue is that what represents "good" or "clean" code is domain specific. All the things are showed you are things that are good for the specific problem of document templating for the web. I'd be willing to say that Perl's flexibility lets you code in pretty much any domain cleanly...if you set up your environment to facilitate that.

Perl is neutral on that spectrum.

No it is not.

Perl has far more tools to support making clean MVC web separation stuff than ruby. The issue is that what represents "good" or "clean" code is domain specific. All the things are showed you are things that are good for the specific problem of document templating for the web. I'd be willing to say that Perl's flexibility lets you code in pretty much any domain cleanly...if you set up your environment to facilitate that.

Probably because the CIO author is highly ignorant of the existence of CPAN and some of the high quality modules it archives and distributes. One particularly high quality module is Template Toolkit. It is an incredibly powerful templating system. Some would even say it is too powerful (you could write enter programs in the template language). But what I have found is that power was purposely put there because there are instances where you need to do something fancy in the template or view rather than the controller code. And I have found it actually turns out cleaner than the equivalent in something built on J2EE.

CPAN is also a whole lot more active than other library inventories. While some authors do tend to give up on maintaining their modules, there are lots of reports and patches submitted along-side the modules as well as test reports on systems where successfully/unsuccessfully installed. There are often multiple submissions of the same concept of a module but with varying implementations. This gives you many choices and lets you explore various implementations until you find one that suits your needs.

Here's a list of other awesome modules that extend perl or implement various concepts:

• RPC::XML - Implement XML Remote Procedure Calls without writing a single line of HTTP, XML, or Socket code!
• Inline - Embed other languages like C directly into Perl code (yes the C code gets compiled!).
• Moose - Extension of objects in Perl, allows more control and adds new syntax sugar to make writing OO programs cleaner/stricter.
• libwww - World Wide Web library for Perl, easily create something like a robot without too much low level detail with HTTP and Sockets.

In other languages or platforms there's also been issues with third-party libraries. For example in Java you could spend days trying to get a library or tool to work in your IDE. With perl and unix that's not the case. You simply go onto CPAN, see if someone's done it. If someone has, you'll be up and running in under a minute.

Probably because the CIO author is highly ignorant of the existence of CPAN and some of the high quality modules it archives and distributes. One particularly high quality module is Template Toolkit. It is an incredibly powerful templating system. Some would even say it is too powerful (you could write enter programs in the template language). But what I have found is that power was purposely put there because there are instances where you need to do something fancy in the template or view rather than the controller code. And I have found it actually turns out cleaner than the equivalent in something built on J2EE.

CPAN is also a whole lot more active than other library inventories. While some authors do tend to give up on maintaining their modules, there are lots of reports and patches submitted along-side the modules as well as test reports on systems where successfully/unsuccessfully installed. There are often multiple submissions of the same concept of a module but with varying implementations. This gives you many choices and lets you explore various implementations until you find one that suits your needs.

Here's a list of other awesome modules that extend perl or implement various concepts:

• RPC::XML - Implement XML Remote Procedure Calls without writing a single line of HTTP, XML, or Socket code!
• Inline - Embed other languages like C directly into Perl code (yes the C code gets compiled!).
• Moose - Extension of objects in Perl, allows more control and adds new syntax sugar to make writing OO programs cleaner/stricter.
• libwww - World Wide Web library for Perl, easily create something like a robot without too much low level detail with HTTP and Sockets.

In other languages or platforms there's also been issues with third-party libraries. For example in Java you could spend days trying to get a library or tool to work in your IDE. With perl and unix that's not the case. You simply go onto CPAN, see if someone's done it. If someone has, you'll be up and running in under a minute.

Probably because the CIO author is highly ignorant of the existence of CPAN and some of the high quality modules it archives and distributes. One particularly high quality module is Template Toolkit. It is an incredibly powerful templating system. Some would even say it is too powerful (you could write enter programs in the template language). But what I have found is that power was purposely put there because there are instances where you need to do something fancy in the template or view rather than the controller code. And I have found it actually turns out cleaner than the equivalent in something built on J2EE.

CPAN is also a whole lot more active than other library inventories. While some authors do tend to give up on maintaining their modules, there are lots of reports and patches submitted along-side the modules as well as test reports on systems where successfully/unsuccessfully installed. There are often multiple submissions of the same concept of a module but with varying implementations. This gives you many choices and lets you explore various implementations until you find one that suits your needs.

Here's a list of other awesome modules that extend perl or implement various concepts:

• RPC::XML - Implement XML Remote Procedure Calls without writing a single line of HTTP, XML, or Socket code!
• Inline - Embed other languages like C directly into Perl code (yes the C code gets compiled!).
• Moose - Extension of objects in Perl, allows more control and adds new syntax sugar to make writing OO programs cleaner/stricter.
• libwww - World Wide Web library for Perl, easily create something like a robot without too much low level detail with HTTP and Sockets.

In other languages or platforms there's also been issues with third-party libraries. For example in Java you could spend days trying to get a library or tool to work in your IDE. With perl and unix that's not the case. You simply go onto CPAN, see if someone's done it. If someone has, you'll be up and running in under a minute.

Probably because the CIO author is highly ignorant of the existence of CPAN and some of the high quality modules it archives and distributes. One particularly high quality module is Template Toolkit. It is an incredibly powerful templating system. Some would even say it is too powerful (you could write enter programs in the template language). But what I have found is that power was purposely put there because there are instances where you need to do something fancy in the template or view rather than the controller code. And I have found it actually turns out cleaner than the equivalent in something built on J2EE.

CPAN is also a whole lot more active than other library inventories. While some authors do tend to give up on maintaining their modules, there are lots of reports and patches submitted along-side the modules as well as test reports on systems where successfully/unsuccessfully installed. There are often multiple submissions of the same concept of a module but with varying implementations. This gives you many choices and lets you explore various implementations until you find one that suits your needs.

Here's a list of other awesome modules that extend perl or implement various concepts:

• RPC::XML - Implement XML Remote Procedure Calls without writing a single line of HTTP, XML, or Socket code!
• Inline - Embed other languages like C directly into Perl code (yes the C code gets compiled!).
• Moose - Extension of objects in Perl, allows more control and adds new syntax sugar to make writing OO programs cleaner/stricter.
• libwww - World Wide Web library for Perl, easily create something like a robot without too much low level detail with HTTP and Sockets.

In other languages or platforms there's also been issues with third-party libraries. For example in Java you could spend days trying to get a library or tool to work in your IDE. With perl and unix that's not the case. You simply go onto CPAN, see if someone's done it. If someone has, you'll be up and running in under a minute.

Probably because the CIO author is highly ignorant of the existence of CPAN and some of the high quality modules it archives and distributes. One particularly high quality module is Template Toolkit. It is an incredibly powerful templating system. Some would even say it is too powerful (you could write enter programs in the template language). But what I have found is that power was purposely put there because there are instances where you need to do something fancy in the template or view rather than the controller code. And I have found it actually turns out cleaner than the equivalent in something built on J2EE.

CPAN is also a whole lot more active than other library inventories. While some authors do tend to give up on maintaining their modules, there are lots of reports and patches submitted along-side the modules as well as test reports on systems where successfully/unsuccessfully installed. There are often multiple submissions of the same concept of a module but with varying implementations. This gives you many choices and lets you explore various implementations until you find one that suits your needs.

Here's a list of other awesome modules that extend perl or implement various concepts:

• RPC::XML - Implement XML Remote Procedure Calls without writing a single line of HTTP, XML, or Socket code!
• Inline - Embed other languages like C directly into Perl code (yes the C code gets compiled!).
• Moose - Extension of objects in Perl, allows more control and adds new syntax sugar to make writing OO programs cleaner/stricter.
• libwww - World Wide Web library for Perl, easily create something like a robot without too much low level detail with HTTP and Sockets.

In other languages or platforms there's also been issues with third-party libraries. For example in Java you could spend days trying to get a library or tool to work in your IDE. With perl and unix that's not the case. You simply go onto CPAN, see if someone's done it. If someone has, you'll be up and running in under a minute.

You mean like mysqli_stmt_prepare ? Looks pretty much like PERL's version

Looking at the examples you linked to, the difference between PHP and Perl in database operations is pretty clear. The PHP function is called mysqli_stmt_prepare, making it obvious that it only works with MySQL. Presumably the code would have to be changed to postgresqli_stmt_prepare,(or whatever the PostgreSQL function is called) if the database was changed from MySQL to PostgreSQL.

Compare that with the Perl version, in which the only difference between code that connects to a MySQL database or a PostgreSQL database is the datasource string. That's the string in your second linked web page that says: "DBI:mysql:database=somedb;host=localhost". For this code to be connected to a PostgreSQL database, that might change to "dbi:Pg:dbname=foo", and the code would then work with PostgreSQL. And the same thing can be done to connect to just about any other database.

That difference alone might be enough to make me want to use Perl in preference to PHP. However, once you start using some Perl modules, the programming job becomes much easier. For example, a lot of PHP code still contains many SQL statements for inserting, finding, updating, and deleting data. Using Perl's DBIx::Class module for example, the programmer will probably not need to write any SQL statements in the program. The module will handle it all. Removing most of the SQL from the program means that a big source of bugs and other problems is gone. And it removes the SQL injection attack problem too as a bonus.

Clearly Perl isn't for everybody. It can be difficult to understand how to use the power of Perl to produce good programs. But once you do understand that, the deficiencies of some other languages become apparent. However, if people want to use PHP for whatever purpose, then good luck to them. I hope it works out well. If somebody likes PHP and doesn't want to change, then they should stick with it. If it does what you want and you're happy using it, then it's clearly a good choice for you.

There are about a dozen Linux applications that will work with the Davis Vantage Pro/Pro2. I have used Stan Sanders vanprod for years without any issues. It is written in PERL, so it is very easy to customize.

There is no way to avoid purchasing the rather expensive hardware interface, which includes the Davis WeatherLink software. I found Provantage to have the best price on pretty much all Davis products, including the I/O interface.

I would highly recommend getting the serial vs. the USB interface, especially if you intend to separate your console and computer by more than 10 feet or so... From what I have read, the serial interface is also less prone to dropouts/locking up, but perhaps that is a Windows USB issue?

One last point... The Davis instruments are very high in quality, so much so that my MADIS QC ratings are even better than most of the local area airports! Yes, it took me a few weeks to gradually "tweak" these values, especially the barometric pressure, but in the end it was well worth the effort.

Tim

There's a third-party Perl module, Net::MySQL, that implements the protocol itself and doesn't link to the MySQL client library - it's not exactly well-maintained, though. Reimplementing the protocol is not technically difficult, but no-one does for licensing reasons because with MySQL's interpretation of the GPL it doesn't gain them anything anyway.

I'll ask you the same question I ask everyone unhappy with "Perl's object system". Which object systems for Perl have you tried?

There is rudimentary object support (enough for many tasks when you're not in need of a full-fledged object system) based on blessed hashes with no enforced encapsulation. That's the one most people consider since it's been around a while and most of the older docs talk about it.

There are also a number of other object systems written as modules that are well supported by the community. Object::InsideOut is pretty popular. So is Moose. You can always just search CPAN for the word 'object' if you want to look at any others.

I'll ask you the same question I ask everyone unhappy with "Perl's object system". Which object systems for Perl have you tried?

There is rudimentary object support (enough for many tasks when you're not in need of a full-fledged object system) based on blessed hashes with no enforced encapsulation. That's the one most people consider since it's been around a while and most of the older docs talk about it.

There are also a number of other object systems written as modules that are well supported by the community. Object::InsideOut is pretty popular. So is Moose. You can always just search CPAN for the word 'object' if you want to look at any others.

I'll ask you the same question I ask everyone unhappy with "Perl's object system". Which object systems for Perl have you tried?

There is rudimentary object support (enough for many tasks when you're not in need of a full-fledged object system) based on blessed hashes with no enforced encapsulation. That's the one most people consider since it's been around a while and most of the older docs talk about it.

There are also a number of other object systems written as modules that are well supported by the community. Object::InsideOut is pretty popular. So is Moose. You can always just search CPAN for the word 'object' if you want to look at any others.

Yeah, I think the basic OO support that was addd to Perl in version 5 leaves a lot to be desired, since it's extremely minimal and requires a lot of typing boilerplate to do even basic stuff. The thinking was to make the most minimal solution and see what people needed.

If you are interested in doing real OO, I'd recommend using the Perl OO Framework called 'Moose', which you can install with 'cpan Moose' is you have a reasonably modern Perl (you might need to sudo that command, btw.)

Moose is a full meta object system with introspection, Roles (sort of like Interfaces on steroids), and a neat syntax. check out the tutorial at:

http://search.cpan.org/~stevan/Moose-0.33/lib/Moose.pm (which is the lastest version as of this posting)

There's also a very active IRC channel at irc.perl.org#moose

If you like Perl but feel envious of languages with more strongly defined OO systems, I really recommend looking at Moose. It's a big step forward for the community and give you one of the nicest and most productive OO systems around.

Perl can be used as a functional language. It can also be used as an object-oriented language, especially if you use a modern OO library instead of the low-level core support for object-oriented development. Perl is also a great structured programing language too, of course.

Other than Systems Programming and Operating Systems, you could use Perl and CPAN to address all of the computer science subjects you mention, and you could use the Inline module and the other modules in its namespace to teach other languages, within the context of a Perl development framework.

I'm not suggesting that universities should switch from all-Java to all-Perl (though doing so would probably improve productivity for most programmers, so long as they're taught to use Best Practices and not create the write-only code that bad/non programmers often create with Perl.) Instead, I'm thinking that an introductory course could teach Perl syntax and best practices, and use that as a basis to provide introductory training in all of the different development styles and subjects you've touched upon. By using one language that is flexible enough to cover this wide variety of material, the topics could be covered without confusing beginning students with a variety of languages.

Perl can be used as a functional language. It can also be used as an object-oriented language, especially if you use a modern OO library instead of the low-level core support for object-oriented development. Perl is also a great structured programing language too, of course.

Other than Systems Programming and Operating Systems, you could use Perl and CPAN to address all of the computer science subjects you mention, and you could use the Inline module and the other modules in its namespace to teach other languages, within the context of a Perl development framework.

I'm not suggesting that universities should switch from all-Java to all-Perl (though doing so would probably improve productivity for most programmers, so long as they're taught to use Best Practices and not create the write-only code that bad/non programmers often create with Perl.) Instead, I'm thinking that an introductory course could teach Perl syntax and best practices, and use that as a basis to provide introductory training in all of the different development styles and subjects you've touched upon. By using one language that is flexible enough to cover this wide variety of material, the topics could be covered without confusing beginning students with a variety of languages.

Perl can be used as a functional language. It can also be used as an object-oriented language, especially if you use a modern OO library instead of the low-level core support for object-oriented development. Perl is also a great structured programing language too, of course.

Other than Systems Programming and Operating Systems, you could use Perl and CPAN to address all of the computer science subjects you mention, and you could use the Inline module and the other modules in its namespace to teach other languages, within the context of a Perl development framework.

I'm not suggesting that universities should switch from all-Java to all-Perl (though doing so would probably improve productivity for most programmers, so long as they're taught to use Best Practices and not create the write-only code that bad/non programmers often create with Perl.) Instead, I'm thinking that an introductory course could teach Perl syntax and best practices, and use that as a basis to provide introductory training in all of the different development styles and subjects you've touched upon. By using one language that is flexible enough to cover this wide variety of material, the topics could be covered without confusing beginning students with a variety of languages.

Perl can be used as a functional language. It can also be used as an object-oriented language, especially if you use a modern OO library instead of the low-level core support for object-oriented development. Perl is also a great structured programing language too, of course.

Other than Systems Programming and Operating Systems, you could use Perl and CPAN to address all of the computer science subjects you mention, and you could use the Inline module and the other modules in its namespace to teach other languages, within the context of a Perl development framework.

I'm not suggesting that universities should switch from all-Java to all-Perl (though doing so would probably improve productivity for most programmers, so long as they're taught to use Best Practices and not create the write-only code that bad/non programmers often create with Perl.) Instead, I'm thinking that an introductory course could teach Perl syntax and best practices, and use that as a basis to provide introductory training in all of the different development styles and subjects you've touched upon. By using one language that is flexible enough to cover this wide variety of material, the topics could be covered without confusing beginning students with a variety of languages.