[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
non-programmer.
* 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.
SteveT
Steve Litt
Founder and acting president: GoLUG
http://www.golug.org
- Curses RAD executables, Steve Litt, 2004/05/09
- Message not available
- Re: Curses RAD executables,
Steve Litt <=
- Message not available