Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"
 
PerlMonks  

Re: Re: Cross platform perl development

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


in reply to Re: Cross platform perl development
in thread Cross platform perl development

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

  • Comment on Re: Re: Cross platform perl development

Replies are listed 'Best First'.
Re: Re: Re: Cross platform perl development
by dragonchild (Archbishop) on Jul 23, 2001 at 16:50 UTC
    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??

      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?)

      While I apreciate your comment, I must say that I strongly disagree with you. Very strict OO languages, can be made very learnable for non programmers by giving it the right interface. Have a look at what Alan Kay have done with Squeak, it certainly have made it very accesible to a lot of very inexperienced children....

      Btw. most newer dialects of Logo are turing complete.. would you really say that Perl is easier to learn than Logo? *grin* =)

      If your users demand scripting capabilities, you can demand knowledge

      he he... but knowledge not including OO? The fact is that the system itself is build around the notion of objects. A web page for example is presented to the administrators as an object viewable through a web browser, so the object based thinking is there allready. For example, if the script writer want the name of a specific user, it might be available as an instance variable on the users object (ie. the page showing the CRM data for the specific user).

      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

      Well.... I do plan to make a GUI which will make an easier entrance for inexperienced users, alongside the full access to the scripts. However, I don't see how this changes the knowledge required towards understanding procedural vs OO thinking.

      Btw... we do alot of game programming, and quite frankly, it is a _lot_ harder than most people think.

      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??

      Well, I didn't plan to kill myself, but simply use a YACC... the right tool can often make a big difference towards how hard a thing is to implement =)

      Kasper

Re3: Cross platform perl development
by pmas (Hermit) on Jul 23, 2001 at 17:33 UTC
    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.

      Do you mean simple PC?

      Hardware wise, yes, but software wise, no... While MS products might seem cheap (Yearh right), to some home users, try equiping even a small organization with around 50 people with Win2K and Office pro licenses.. not a pleasent experience.

      Furthermore... I reeeeally don't like access, for everyday I have used it, I have become more and more sure, that it is actually just minesweeper with a few added lines of code =)

      ...well maybe that was a bit harsh, i find access very adeqate (..hmm.. aparently my english spelling abilities have gone after just two beers) for some smaller jobs, but would rather not use it for anything so serious that I could not just as easily have used text files for the job.

      Kasper

        I am afraid my point - "use Access if you have it already" on your Windows machines was not obvious enough. :(
        I do not agree about Access with you. It is excellent for first-time, inexperienced users, for casual access to data. I am not aware of any other DB interface (for the price) with so easy to use visual query builder, or "query by form". You cannot beat easiness of building SQL table JOINs visually.

        Sure enough, when you need to do more serious development, you are seduced to MS concepts, but can avoid it by using DBI, ODBC and perl. With DBI, perl, and little thinking , I may not care what database I am connected into.

        Access (== MS Jet database engine) has record locking and transactions as real databases have, which I doubt about text files... ;)

        And sure enough, if you do not need PC, and free *NIXish system is acceptable for users, just go ahead.

        Installed OS is not a "religious issue" for me. User needs to be comfortable with the OS selected, and luckily enough I can port my perl on almost any system (there was discussion about porting Perl to Palm PDA- can you believe that?).

        Obviously, if users like to try to equip 50 PCs with Linux and StarOffice, excellent - Micro$oft is rich enough. If I may not care about transactions - so mysql is enough, it's fine. I did not use Postgress DB, so I cannot recomment id. After many years using database PROGRESS and it's clever 4GL language, I am back to plain stupid SQL on ORACLE, and only perl makes this experience bearable... ;)

        And I am sure Access is more than minesweeper: Access can do transactions and rollback, but minesweeper cannot. :)

        Update: Full disclosure: I am using Access/ODBC connection to ORACLE database to check how my CGI scripts are working. I found it easier - because I know it already...:)

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

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (None)
    As of 2021-10-17 21:50 GMT
    Sections?
    Information?
    Find Nodes?
    Leftovers?
      Voting Booth?
      My first memorable Perl project was:







      Results (72 votes). Check out past polls.

      Notices?