Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

Cross platform perl development

by kapper (Chaplain)
on Jul 23, 2001 at 15:16 UTC ( #98967=perlquestion: print w/replies, xml ) Need Help??

kapper has asked for the wisdom of the Perl Monks concerning the following question:

Hi there fellow monks... here comes a little bag of questions I have acumulated over the last few weeks. I have been able to find answers for most of the questions, but would like your comments in the context of the system I am about to implement.

I am about to start a larger project in Perl on very unfamiliar grounds. We are about to write a cross platform enterprise component framework. Initially we where going to implement it in PhP with PostgreSQL under GNU/Linux and in vb script with COM objects and MS SQL7 under Windows. However... I'm so fed up with PhP that I no longer wish to undertake any projects much larger than "hello world" in it....

...then it hit me, why not write it in Perl? that should be ok performance wise under both Windows and GNU/Linux? (any comments and that assumption would be greatly valued)

Sooo.. my main question, since I have basicly no experience with database connection handling under Perl, I have no idea about what database to choose under either Windows or GNU/Linux. Since we have chosen to use the same language on both platforms, it would be nice to use a database connection module which would work seamlessly on both platforms, and thereby completely remove the double development. Which DBMS would you recommend for each platform? It should be a full functioning DBMS with subqueries and transaction support (in other words no MySQL). A free DBMS would be preferable for at least one of the platforms.

Ok, next question... in the system, we will need to implement a small OO language. We where going to write the runtime environment as a native C++ library, but since we are now using Perl, it would be so much nicer to implement it directly in Perl. However, this would mean having a vm in a vm.. not exactly a high performance solution. Although performance is not the only factor (our system supports clustering), it is important. Do any of you know of any vm projects in Perl, which have some benchmarks, wich gives an idea about what kind of performance one could expect.

Anyways, thanks for your time, I know these where not excactly Perl programming specific questions, but I really needed some input from experienced Perl programmers on the questions in the context of an enterprise component framework. Any other comments on the subject would also be greatly valued..

thanks,
Kasper

Replies are listed 'Best First'.
Re: Cross platform perl development
by MZSanford (Curate) on Jul 23, 2001 at 15:24 UTC
    For Database connections, i would look to DBI for whatever database engine is chosen. It is the standard, is stable, and has a clean interface. As for the database engine, i have used MySQL and Sybase quite a bit, and have found that if MySQL cannot handle it, Sybase usually can.

    On the vm within a vm, i am no help. I have implimented scripting languages in Perl using either source filters or Parse::* modules ... but with only some success.
    remeber the immortal word's of Socrates who said, "I drank what ?"
Re: Cross platform perl development
by simon.proctor (Vicar) on Jul 23, 2001 at 15:55 UTC
    If this project is as large as you make out then the platform for it is not really an issue. Whether you use MySQL, PostGres or SQLServer (amongst others) you will want them on their own machine and connect to them via the DBI and the relevant DBD driver (ODBC, PG etc).

    As for a scripting language - why not use Perl itself? You can quickly define a set of macros and comeup with an application object that presents a partcular API. Its then trivial to check for bad code, to untaint and to run the app.

    Through your API you can also abstract any common tasks and allow the 'programmer' to do stuff quickly and easily.

    If you are using Perl because of simplicity and power - why not use it throughout?

      If this project is as large as you make out then the platform for it is not really an issue. Whether you use MySQL, PostGres or SQLServer (amongst others) you will want them on their own machine and connect to them via the DBI and the relevant DBD driver (ODBC, PG etc).

      I totally agree with you on that for large sites, but the system must easily support small sites as well as large. In other words, we need to have an install plan, that will work nicely on a small server, as well as for large clusters, where we offcourse as you suggest, will have dedicated database servers. Another issue for some of our smaller customers, is cost, some of the larger DBMS's can have a pretty hefty price tag. Therefor, the system should work with both a small preferably free DBMS, as well as a large commercial DBMS on a dedicated server.

      As for a scripting language - why not use Perl itself? You can quickly define a set of macros and comeup with an application object that presents a partcular API. Its then trivial to check for bad code, to untaint and to run the app.

      ...would be pretty cool from a programmers point of view =). I did give it a few thoughts earlier, but dismissed it as beeing to hard for non programmers to learn.... aaand, I wasn't sure how to go about with the "bad code" checking... anybody have any pointers to some information about that? similar projects or something like that?

      thanks for your reply! it gave some good food for further thoughts...
      Kasper

        I was part of a project that, among many other things, created our own scripting language. It was extremely basic, using \n to indicate the end of a statement and implemented only SET/JMP/JZ/JNZ/IF/ELSE/ENDIF/WHILE/FOR/RETURN. That was it.

        Now, this wasn't OO. However, what concerns me is that you want to create an OO language and expect non-programmers to be able to handle it. That's got "Bad Plan"(tm) written all over it. Perl is the easiest "real" language to learn, except for VB. (Maybe that's why M$oft made VB their scripting language of choice?) Start small. If you're smart in your design, the language should be upgradeable without impacting anything else. (Maybe a Script::* set of modules?) Plus, demanding that your users actually understand the basics of procedural programming isn't unreasonable - it's almost expected, these days. If your users demand scripting capabilities, you can demand knowledge. (Unless, of course, you were planning on writing a GUI "editor" that allowed them to drag-and-drop statements from a list... if you're doing that, quit your job and write a game.)

        As for bad code checking, use eval. Let the interpreter check bad code for you! Oh, you can do basic easy stuff, like balance parentheses and the like, but don't do any complicated syntax or nothing. Why kill yourself when Perl does it already??

        As a small database on small system:
        Do you mean simple PC? I run MS Access with 3GB database, and it survived. MS Access is "free": bundled in MS Office pro, you have MS Office anyway, right? You can access Access database (MS Jet Engine) via ODBC and DBI just fine. Your SQL will be multi-platform as long as you will use only standard SQL and avoid any proprietary extensions - but DBI will wisely guide you to use standard SQL only ;)

        pmas
        To make errors is human. But to make million errors per second, you need a computer.

Re: Cross platform perl development
by gwhite (Friar) on Jul 23, 2001 at 15:55 UTC
    There are not that many gotcha's writing cross platform especially when you stay within the realm of Perl (not using system specific things like sendmail). DBI is the way to go, I have scripts that run on several flavors of Unix and Win with the only change being the connection string to the database. I believe also the latest version of MySQL does support transactions (not sure about subqueries), but by using DBI you can use MS SQL on the windows box and "something else" on the *nix boxes. Or access the MS SQL server box from whatever platform you run the scripts on.

    Mod_perl is most likely something you want to investigate for your VM.

    good luck
    gwhite

Re: Cross platform perl development
by Cubes (Pilgrim) on Jul 24, 2001 at 17:38 UTC
    Take a look at Cygwin. With it on a windows box, I have run Apache, <a href=http://perl.apache.org">mod_perl, and postgreSQL, and have been able to carry my development environment around with me on my (windows) laptop. With just a little extra care and effort on my part to make my code portable, I was able to plop everything onto a linux box and crank it right up.

    Update: Fixed the cygwin link

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://98967]
Approved by root
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others surveying the Monastery: (5)
As of 2021-11-27 15:39 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?