[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Curses RAD executables

From: Steve Litt
Subject: Re: Curses RAD executables
Date: Mon, 10 May 2004 09:16:27 -0400
User-agent: KMail/1.5.3

On Monday 10 May 2004 08:01 am, Eric Lenio wrote:
> Steve, why not just one executable with subroutines for menus, forms, and
> picklists?  What is the benefit of 3 separate programs?

Hi Eric,

Thanks for asking this question, because it invites me to showcase the true 
goals of my intended RAD project. You ask why several executables are better 
than one:

* Application programmer can pick his own language
* Debugging is hugely simplified with independent programs
* Executables are simple, tested, testable, and known good
* GPL tool that produces code of any desired license, including proprietary
* Thin interface modularity produces very quick coding.
* To a certain degree, the separate executables could be used by a 
* Extremely simple apps could be implemented as shellscripts.
* Ability to put apps together like Lego(R) blocks or 74xx chips without the 
object and subroutine interactions that invariably crop up in monolithic 
applications or toolsets
* Other executables will include a database executable (basically a front end 
to psql), and various adapters that adapt the form, picklist and menu 
executables to a more DBMS-centric format.

To get a gut feel for the advantages of independent executables, think of all 
we do on a daily basis with awk, sed, grep, cut, head, tail, ex (command part 
of VI) and wc. Using their stdin and stdout as connectors, very much like the 
connectors on the back of your stereo system, we can quickly perform almost 
any reasonable parsing task using these executables. Add yacc or bison and 
you can remove the word reasonable.

Like your stereo system at home, these executables are completely mix and 
match. Any one of them is instantly replacable -- unplug it and plug in a 
different one. Each can be tested in isolation. There's a very well defined 
needed input and specified output. Patch cords and adapters are cheaply and 
widely available.

There's nothing we do with these tools that we couldn't do with Perl, Python, 
C, C++, or Java. But very often, for small to small-moderate projects, we can 
do it quicker with the independent tools. And the debugging phase with the 
isolated executables is much faster.

DISCLAIMER: Nothing in the preceding should be taken to imply that I'm not 
very interested in Eric Lenio's all in one Perl Curses toolset. In fact, I'd 
like to participate in that project as a documenter.


Steve Litt
Founder and acting president: GoLUG

reply via email to

[Prev in Thread] Current Thread [Next in Thread]