Re: ada without ada libraries?

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

On 09.02.12 12:08, Gautier write-only wrote:
> Interesting debate: theoretically, I would support fully Yannick.
> But when looking at my practice the strange fact is that the only DSL
> I'm using is command-line interpreter scripts.
> I can do everything else straight in Ada, even:
> 1) on-purpose data conversions, sorting, aggregation (in one case,
> replacing a R script; the Ada version ran hundred times faster and
> solved a data modelling bottleneck for several people)
> 2) 3D models (instead of VRML or MAXScript)
> 3) random language generators (Ada is used there in a purely
> functional way)
> 4) recompression of Zip archives by calling different Zippers and
> taking the best compression ratio
> 
> In cases 2) and 4) I can definitely do a lot more than using a
> corresponding DSL

I'd view this from a different angle, too. It isn't decisive,
I'm sure. The difference is not in the vocabulary, or in
convenience. Rather, there are things that one can do at the
language level (whatever the problem domain is) that is not
easily done using another language.

Suppose that some programming language has both data types
and associated sets of operations that are fundamental to handling
objects of this data type. Like one would expect addition to be
available with objects of numeric types. Such operations could
be somewhat like Ada's intrinsics, or like type attributes. Or they
could be somewhat like the schematic patterns of operations on
containers, etc. In any case, they, too, follow the conventional
scheme of (values, operations). But, what makes them different
is the kinds of values on the one hand and their "initial functions"
(from which to built more operations) on the other.

Suppose that data from some problem domain have a physical
structure that is very much comparable to the structure of the
above mentioned data types (data types as-is, not composed).
Likewise, the typical ways of using the data in the
domain are comparable to (language-based) operations on objects
of that data type (the "initial functions").

Then, "operational modes", the ways of doing things in the domain
will actually suggest such a "matching" programming language.
For example, "search" � la Prolog, or "generators" � la Icon
have influenced the types of built-in data structures and operations,
and have also influenced the interpretation of expressions.
The result is a different language, but a suitably different
language that is still a general purpose programming language.

The choice of a domain specific programming language in this sense
will be influenced by the domain: the data structures of the
domain might match the data structures in the language better.
The operations in the domain might match the ones of the language
better.

The difference between the languages when seen from this angle
is this: no need to produce yet another DSL to get language features
that are valuable in some domain.