I believe with a former post the problem is not with Perl as a language but with the maturity of most of the programmers that use it. Thinking about what makes code maintainable does not usually enter a programmers mind until he has the privilege of trying to maintain a code base that was done by another team. I know by experience that no one really thinks about what will happen if I leave and someone else has to keep this running until they are the one that has to keep someone else's program running with bug fixes and extra features. That being said maintainability of a code base is really done in the design part of the project and Vista had some really good design elements in for it's time, it should be gone through and the design should be brought up to current times.
Thanks Marc Aylesworth C3I Associates AFRL/IFSE Joint Battlespace Infosphere Team 525 Brooks Rd Rome, NY 13441-4505 Tel:315.330.2422 Fax:315.330.7009 Email: [EMAIL PROTECTED] -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ruben Safir Sent: Wednesday, August 17, 2005 12:54 AM To: [email protected] Subject: Re: [Hardhats-members] GTM Perl On Wed, 2005-08-17 at 00:33, Jim Self wrote: > Suchi Pande wrote: > >Aylesworth Marc A Ctr AFRL/IFSE wrote: > >> Perl has a datatype that is a hash and can be accessed by the bucket name > >> but it does not require distinct keys so that anything on the node would be > >> returned as a list or Vector like datatype. > >> > > > >The classic data structures reference book for perl is Tom > >Christiansen's "perl data structures cookbook". > > > >My opinion: > > > >The trouble with perl as a language is linked to one of its strengths > >- namely TMTOWTDI (or: There's More Than One Way To Do It). > > > >This means that idioms keep coming up in perl, that people find hard > >to understand. So that code is often unreadable to others. This, > >together with the "line-noise" look of the code makes it hard to > >maintain later on by even the coder, let alone others. > > I don't know that Perl is the best complement to MUMPS as they seem to share some similar > strengths and weaknesses. It's simply the one that makes the most sense to us as a > starting point for building out our server base from MUMPS to integrate with other > server-side programming languages. > > One reason that we have started with a GTM to Perl interface is that one of our > programmers is strongly passionate about his preference for programming in Perl as "the > one true language" ;) and we wanted to encourage his passion for programming, if not > specifically for Perl. > > I am intrigued with the possibility of writing a web oriented replacement for Fileman in > Perl, or perhaps Python, or PhP, or Javascript in combination with GT.M. > It s a good choice and most of the complaints about Perl amount to petty jealousy. After looking at some of the code I saw scroll across this list in the last few days, a Perl interface is going to be downright peaceful. Ruben ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Hardhats-members mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Hardhats-members mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members
