Your post is stimulating for a few reasons.
One, though not mentioned, your Perl products must have used extensive logging and transaction control, in addition to secure file transfers.
Second, the big problem with Perl in my opinion are the types of texts published about it. There are reams of books on the Perl language but very few about Perl as the language for architecting complex systems.
In contrast, look at the catalog for Addison-Wesley, for example. There are books there on Java regarding Business Logic, Intelligent Agents, Design Patterns, Full E-Commerce Solutions. In other words, many of books on the subjects that grab the attention of CIOs and CEOs of major corporations.
In my opinion, KM, you need to do more than tell us about how this is done. You need to write a concrete text showing HOW it is done and WHY Perl is best-suited for the job. For, if we had to do something of this scale and robustness, most of us we would be lost. | [reply] |
One, though not mentioned, your Perl products must have used extensive logging and transaction control, in addition
to secure file transfers.
Oh yeah. Everything was logged, replicated, backed up, etc... There were two DBs used, Informix and MySQL.. both backed up daily, and
using transactions (we did some hacking to replicate transactions in MySQL in various ways). Any files
which were transfered anywhere were encrypted and digitally signed.
Second, the big problem with Perl in my opinion are the types of texts published about it. There are reams of books on
the Perl language but very few about Perl as the language for architecting complex systems.
Well, in the book I just finished this is somewhat taken care of, in a roundabout way. It is about writing CGI apps with Perl.
In the book, many things are shown, which as a whole should give the reader an idea of how to use the various Perl tools to write applications.
Although the book is geared to CGI, the concepts are the same.
One of the problems I see, is that people (CIOs, et al) may not think Perl can do what it can do, so they use a buzzword compliant language.
Hopefully, they use the Right Tool for the job. If that is C, so be it. If it is Java, then so it is.
I don't know that books on architecting complex systems with Perl would make people do it. First, you need to know how to
architect a complex system, then choose the tool(s) to make it a reality.
Another project we worked on was a portal between vendors. The central server for this was
done in Java, and the grunt work with Perl. Many robust systems use different tools to accomplish what the blueprint lays out.
You need to write a concrete text showing
HOW it is done and WHY Perl is best-suited for the job.
Do I? How would I show you how it is done (I can't show you the code)? Nothing magical was done, heavy DBI usage, cron jobs,
CGI, some Win32 Perl, etc... Nothing that hasn't been explained a billion times already. Most of the it was on one side you have a
FourGen interface into Informix, scripts that move data from Informix to MySQL, a web front end to MySQL, and scripts that move data
from MySQL to Informix. Perl handled all EDI transactions, putting them into Informix, which replicated to MySQL, etc...Not brain surgery.. just timing and
having a decent blueprint to create the system around (many flow charts, specs, test cases, and more flow charts).
For, if we had to do something of this scale and robustness,
most of us we would be lost.
Why would people fail? The only reason I could think of is not knowing what Perl can do, or not knowing how to do it.
That is the fault of the individual, not on the size of the system. I mean really, many systems today are "Put crap in a DB, take crap out of a DB".
Figuring out what to do with the crap, validate the crap, munge the crap, display the crap, etc... are the details
architects and developers need to figure out. That is the hard part.. writing it in Perl is the easy part.
Cheers,
KM
| [reply] |