I have been giving a lot of thought about Microsoft Access. It's a neat little product even though I am not a big fan of Microsoft. What has me thinking along these lines is that my current employer sells a product with a similar goal for Unix/Multi user systems.

Now I'm thinking maybe the goal isn't so bad. A system you half configure, half program. With the whole forms and configuring tables through the use of wizards. There might even be a macro language available. But when things get complicated the system uses perl with a few custom DBI and UI modules. I've always thought that perl is great for anything under 1000 lines but anything larger gets nasty. This might be an approach to split up a large system making a perl based system easily maintained.

The product could be used for a basis of a whole slew of enterprise based systems and might further the idea virus we call 'Perl'.

Any Suggestions/Heckling?
----
visit http://www.atlantageek.com Atlanta's Tech Scene

Replies are listed 'Best First'.
Re: Perl Application Platform
by Biker (Priest) on Dec 19, 2001 at 18:48 UTC

    I'd say that Perl does scale very well, assuming that the programmer 'does the right thing'. Like 'modularize'. I do not think Perl is neither better nor worse than most modern programming languages on this. If any difference is there, I'd say that Perl scales better than some modern languages, but I may be biased there. ;-)

    OTOH, I do have some nasty experiences from MS Access not scaling very well because of technical limitations.

    "Livet är hårt" sa bonden.
    "Grymt" sa grisen...

[reply]
(ichimunki) Re: Perl Application Platform
by ichimunki (Priest) on Dec 19, 2001 at 19:16 UTC
    Oddly enough, almost every major Access undertaking I've done myself was easily written in well under 1,000 of Perl. I use considerably less code for the dynamic portions, and all "table" data was stored as flat files-- space efficiency! I needed no more "queries" since a simple sub usually transforms the raw data into analytical data with much more clarity.

    The final kick for me is that comparable functionality (especially ODBC access) runs in a fraction of the time. Now, I could be incompetent with Access, but I've used it for about three years to do stuff like this and it never gets any easier. On the other hand, I am frequently able to re-use and adapt my Perl scripts in record time.

    I'm not sure an environment is needed, other than emacs for writing the Perl code. *grin* I wrote instructions on installing ActiveState Perl on a Windows environment that were just a few pages that were (imho) fool-proof (standard fool disclaimers apply). And encouraging people to learn Perl itself rather than relying on a system makes the most sense to me. It's not that hard. And it beats having to learn a whole tool and a macro language which is not necessarily portable outside the tool.

    So my only heckle would be: teach them Ruby instead! The Windows install for that includes a Net module and Tk support, which means that my three page install manual is one line: the URL for Ruby and the words "run installer". Of course, I'm kidding. Maybe.
[reply]
Re: Perl Application Platform
by drinkd (Pilgrim) on Dec 19, 2001 at 18:54 UTC
    From my limited Access use, the most time has been spent writing the VBA code to parse through various (ascii, mostly) source files to get the data to load the database with. I think a lot of folks use Acess in this way, since if the data was already available in a nice database format (ODBC "source") then there isn't much reason to put it into Access.

    From this point of view, a similar product with a Perl engine for extracting data from the sources would be a great improvement. Perl would also be very good for report generation, as the MS model of sending to word doesn't really cut it for creating reports for machines to read.

    All of this is doable now, of course using OLE scripts, but the VBA integration with Access is so much easier in general.

    drinkd

[reply]
Re: Perl Application Platform
by Caillte (Friar) on Dec 19, 2001 at 22:03 UTC

    I have never been able to get to grips with access and, any time I have had to do something in access I tend to give up and write the thing in perl, using DBI::ODBC. Personally, this sounds like a great idea.

    This page is intentionally left justified.

[reply]
      I'm just trying to make sure. That last statement. were you being sarcastic?
      ----
      I always wanted to be somebody... I guess I should have been more specific.
[reply]

        No sarcasm, for once ;) Seriously, I find the access interface almost impossible to work with. I dont know why as I can use other MS products... it just seems to be me.

        This page is intentionally left justified.

[reply]
Re: Perl Application Platform
by toma (Vicar) on Dec 21, 2001 at 09:53 UTC
    There is a user interface builder called Glade, which typically generates C or C++ code. There are glade modules to get Glade to work with perl. The UI configuration information is stored in XML.

    I wrote something that is like a subset of Glade but it is much simpler and uses Tk and XML. I use it to create programs that are about half XML configuration and half perl. I wanted people who didn't know perl to be able to create a configuration by hand-editing an XML file.

    The most common Perl Application Framework is the web, using CGI programs to interact with a database. This is less interactive than perl/gtk, but usually easier to program, unless you have especially demanding security requirements. System administration sounds like it would have some of these security requirements, but I have used little rack-mounted linux boxes that are nicely administered through a web interface.

    It should work perfectly the first time! - toma

[reply]

Back to Meditations