Re: Some exciting new trends in concurrency and software design

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

On 6/23/11 12:57 PM, Yannick Duchêne (Hibou57) wrote:
> Le Thu, 23 Jun 2011 12:25:00 +0200, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> a écrit:
>> This is a weak argument. The strong one is that the mathematical numbers
>> used in engineering are simply incomputable. The question is not efficiency
>> ("how"), it is "if": you cannot represent numbers involved, e.g. real
>> numbers. Engineering computations are on the model numbers, where range is
>> just one constraint among others.
> Was indeed what I wanted to mean (yes, even SML is not able to really express the ideal nature of numbers, and nothing is able to).
>
>> All programming is actually about constraints, which makes things so hard,
>> mathematically, algorithmically and also in terms of types (e.g. LSP
>> violation). Ignoring this does not help.
> Ignoring things can help.
>
> There is always some stage where you ignore some one of some other things.

Ignoring things is a pattern in programming whose consequences,
while known to turn out expensive, are consistently ignored, too.
A pattern, incidentally, that seems to have been strikingly absent
when the HOLWG collected a catalog of language requirements more
than 30 years ago.

Ignoring some things can set the stage for successful software
business, since ignoring things allows concentrating on a model that
is simple, and clearly defined.  A simple to use framework is an
example.  Or a cute sequential scripting language. Or some easy to
program mapping of objects to relational database tables. (Or the aspect
of a FPL that interests you most.)

These simple offerings have a few characteristics in common:

- They are all simple.

-They can therefore be understood and handled by many.

- They are therefore attractive,

So they are seen as having potential.


Alas, the potential turns out to be highly energetic.

When the potential of simplified attractive offerings is activated,
its first effect is that "the market" quickly establishes businesses
around the simple offerings. It also establishes a workforce that
accumulates knowledge about these things; some will know the
framework, some will have learned the scripting language, some will
have started mapping objects to RDBMS tables.

(Ada, I guess, has had its new market, too, but for different reasons,
not because things had been ignored.  "The mandate" would help create
Ada business in those years.)

Second, the offerings' potential, when moving the marketm is then starting
to generate an ecosystem of work.  Work that isn't easy, frequently not
fun, and not very productive: work that is about tackling the things that
have been ignored.  Such as:

- when the framework turns out to be little more than boilerplate
text---but otherwise requires detailed knowledge of a vast configuration
sublanguage.

- when the scripting language is used to process international text
in a concurrent environment and fails, since char issues and concurrency
have been ignored.

- when the program's data model turns out to be relational, but
the object-as-a-table magic does not quite work.
The workforce then finds themselves trying to reinvent a relational
database management system, investing man months ...

The reason that in the context of FPLs I'm mentioning this pattern (of
deliberately ignoring some things being a cause and expensive work
being an effect) is that one of these languages, the ATS language, is
really highly efficient by design and also includes a proof system
right in the language. It has safe pointers, too. So it would seem
promising.  Even as a layman, I am sure there are many interesting
advancedfeatures in ATS.

But as usual, some things have been ignored.

As far as I can tell, at least these:

The numeric types are, by default, basically int of ISO/IEC 9899 (C).
A factorial function of a large enough argument may therefore
return a number < 0.  Likewise,  watch the program

implement main() = begin
    print_int(4000000000) ; print_newline()
end

$ ./a.out
-294967296

O'Caml appears to be operating at a similar level, if my copy
isn't broken:

# let i = 4000000000;;
val i : int = 4000000000
# i * i;;
- : int = -2446744073709551616
#

The puzzling issue is why don't functional programmers just copy
the solution from Lisp, such as CMUCL?  Or from Python? Are they
ignoring even "their own relatives"?

* (let ((i 4000000000))
     (* i i))

16000000000000000000
*

>>> i = 4000000000
>>> i * i
16000000000000000000L

Won't it be a good idea to first collect requirements for a system
of fundamental types such as whole numbers for use in new languages?
Then implement them for new functional languages. So as to *not*
build new ideas atop ISO/IEC 9899 and spoil it with the consequences
of importing int.  Doing so seems like breaking future software by
design.


Continuing things ignored in ATS:
Syntax. Programmers will need initiation into another interpretation
of ASCII punctuation.  ATS does use ASCII symbols, which may be a lot
better than words insofar as symbols are as international as "+".
The symbols have precisely specified meanings. But they have these
meanings in just this language.  How many programmers use just
one language?  The situation is worsened by overloading ASCII
symbols, which according to Australian studies does not seem
to help newcomers understand source text.  (Which, incidentally,
is an argument against Ada's X(42) meaning both array component
and call.)

Concurrency.  ATS does address concurreny---with POSIX threads
and such. Well, that's at least something. Or maybe not?

ATS appears to be a research work, too.  I understand that Haskell is
the outcome of a collaborative effort to create a FPL that would have
desired properties.  Maybe ATS work will at some stage be integrated
into some FPL.  Hopefully, though, only the ideas will be adopted into
contemporary programs, not the underlying fundamental types.
How can a safe ATS pointer be safe in the presence of int ?

In the long run, I don't think it is a good idea to ignore things
as often as it is actually done, and supported.  The pattern,
whether employed in language design or in programming, will generate
insecure software and entail costly repair.