🚀 go-pugleaf

Paul Alexander (pa@mrao.cam.ac.uk) writes:
[...]
: I am a fairly late convert to the
: strengths of multi-language programming in a single application, but
: now converted I would never go back to my old ways.  It is essential to
: remember that most people using computers are not programmers at all; this
: is now true even in a physics lab and has been brought about by the excellence
: of special purpose languages (mostly now Maple and Mathematica!!).  I write
: applications for this audience and they demand applications which have
: an easy to learn extension language.  Tcl is ideal for this, its simplicity
: of syntax (it IS for non-programmers who have never seen C!) makes it very
: popular among USERS.

C++ provides an interesting way to address this. The language is internally
extensible. Thus one can define a matrix class and define the standard
operators: +, -, * etc to be the standard operations on matrices. That
is the approach I adopted in ObjectProDSP. Rather than create a new
language for defining Digital Signal Processing (DSP) networks I used the
internal extension capabilities of C++.

This approach does not force one to use a compiler. I wrote an interpreter
for a fragment of C++ that allows one to use this language interactively.
Then I provided facilities for creating and editing networks using menus
and the mouse. These actions generate statements in this DSP language
and those statements are interpreted interactively to create DSP nodes
and edit them into a network. A user can start with only knowing about
menus and which mouse buttons to click to edit a network. This is all
she needs to fully use my tool. If she wants she can quickly
come to understand the DSP language statements that are generated (and
can be displayed) when she edits a DSP network graphically. In many cases
it can be quicker to write this code directly rather then play with
the mouse and menus. This code no matter how it is created and no
matter how little the user knows about C++ is syntactically correct
C++ code.

With this approach I have defined an application oriented language that is
easy and natural for people working in DSP to understand and use. Because
it is done in the framework of C++ it can be extended to support anything
that can be supported in C++. If you start with a lesser framework you are
almost certainly going to adopt syntax conventions that sooner or later will
come to haunt you and limit the extensibility of your language.

Of course C++ is not an ideal language and Richard Stallman is critical
of its syntax just as he is critical of Tcl. Bjare Stoustup made a deliberate
decision in designing C++ to maintain nearly complete upward compatibility
with C. The result is a syntax that is not ideal but has been of enormous
practical value.

C++ may not be the perfect foundation for application oriented languages
but it is the best practical foundation we have today. It is a foundation
that allows the language to grow indefinitely and still maintain a reasonably
clean structure. This is an essential element if a language is to grow over
time to include more applications and more sophisticated operations in
the applications it addresses.

The architecture of ObjectProDSP and ObjectPro++ were designed to support
such indefinite extensibility. The challenge is not to provide a language
that addresses a single application area but to provide a framework for
integrating many application areas so they work together. We need to do
this in a way that each application has a language that is natural and
intuitive for those working in that area. That is the problem I was
addressing and why I choose C++ as a foundation for my application language.

Paul Budnik

ObjectProDSP and ObjectPro++ are available at:
tsx-11.mit.edu directory /pub/linux/packages/dsp
SunSITE.unc.edu directory /pub/Linux/devel/opd
ftp.funet.fi directory /pub/OS/Linux/util/electronics/opd
Please use the mirror site nearest you.