Re: Some exciting new trends in concurrency and software design

["Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr>]

Le Fri, 24 Jun 2011 00:17:23 +0200, Georg Bauhaus  
<rm.dash-bauhaus@futureapps.de> a écrit:
> Ignoring things is a pattern in programming
Funny wording :)

> 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.
Please, tell more

> 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.
Yes, that's the purpose of modeling. But this does not include on-purpose  
erroneous design, as you erroneously suggest later (seems you've ignored  
some possible views on the topic :-P ).

> 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.)
I was not talking about FPL in the large, as I know only one, which is SML  
(others are too much different). And this one was not designed to be cute,  
but to be sound. It was specified prior the first implementation (as you  
know I guess), just like Ada was, and this specification was not based on  
The Great Cute Levels Catalog, but made of coherence proofs instead.  
Unfortunately, you've made this error so much early, that a large part of  
what you wrote since here is unclear due to that assumption. But you are  
still OK, as its my sole fault I was too much imprecise about the meaning  
of “forget” (will be clarified a bit later).

> 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,
None of the three applies here.

> So they are seen as having potential.
Not really, as people complains the crowd did not adopted it (true for  
Haskell too).


> 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:
Hey, I was not talking about Python!

> - 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.
Not a language failure, but an application design error.

> - when the program's data model turns out to be relational, but
> the object-as-a-table magic does not quite work.
Wrong analysis. No language can avoid this, as this is often prior to  
enough text in any language, except human's languages.

> The workforce then finds themselves trying to reinvent a relational
> database management system, investing man months ...
You end into reinventing paradigms when you used the wrong language for  
the wrong thing, which was what I was arguing against in another message  
to someone (nicely) stating Ada is the best language ever for everything.  
I would not promote SML as the best language for everything, not more than  
I would do this for Ada. You have to feel that SML is well suited for one  
task prior to use it, or else, don't use it. In short, I would say SML is  
well suited when 1) you want to express some kind of algorithm with the  
safety of avoiding side effects (which Ada can't prevent by nature) 2)  
when you want to express an algorithm with some terseness, which is  
something I know Ada lawyers will argue against, but which is anyway  
better than abstract comments in an Ada program, which would be controlled  
in no way and which would be too much interleaved with the Ada text to be  
of real readability help 3) when you want expression based text, which may  
help proof by any mean (by hand, or why not automatic). To be honest, Ada  
provides tools for the latter, especially since Ada 2012 and its  
conditional expressions. But it still lack terseness and easy avoidance of  
side effects. Never mind, it should not provide these, as this is not its  
purpose.

When I said “forget things”, I meant for example, forget about number  
limitations, explicit annotation of type (which are anyway statically  
explicit to the SML compiler, thanks to type inference) to help terseness  
and then provided a better view of the whole with less cognition load, and  
forget about any other kind of memory concrete things, like available  
memory, including memory management.

When you start forgetting such things, you do not build anything  
erroneous, you just create something which will need to be refined and  
specialized, which is different than something which will need to be  
totally redesigned.

You may think of it as HTML+CSS, where HTML is the core of the meaning and  
CSS the layout layer: the core meaning of an algorithm may be the SML  
text, and the meaning+presentation would be the concrete implementation to  
be presented to some machine or hardware, the one which is better  
expressed with Ada, due to many of the requirement at this stage.

If HTML forgets about presentation, that's for a good, and this does not  
lead to erroneous pages. This leads instead to pages with potentially  
multiple implementation, due to clean separation of both, just like an SML  
text may have multiple Ada implementations, depending on requirement:s  
memory limitation, concurrency available or not, preference for sequential  
implementation or not, use of garbage collector or not -- which I  
personally dislike, available or recommended width for numbers, etc. This  
is of no help at all to introduce all of these too much early, this would  
have the same effect as obfuscation.

> 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.
Yes, Among others, modularity (I still not tried this one, sorry, just  
read about it).

> 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
Does not stand for what I was suggesting to forget about. Otherwise I  
would have suggested to simply leave Ada ;-) and I didn't.

> 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
> #
Do you know what SML proponents says about OCaml ? They complains the  
fundamental principles of SML were sacrificed to efficiency, it is  
suspected to be less sound, and to be less safe due to heavy use of side  
effects.

Let's try it with SML:

    Moscow ML version 2.01 (January 2004)
    Enter `quit();' to quit.
    - val i = 4000000000;
    ! Toplevel input:
    ! val i = 4000000000;
    !         ^^^^^^^^^^
    ! Lexical error: integer constant is too large.

Oops, integer too large, so let's drop a zero (I did not checked MoSML  
specific limitations)

    - val i = 400000000;
    > val i = 400000000 : int
    - val j = i * i;
    ! Uncaught exception:
    ! Overflow

Either a compiler error or a runtime exception. And that's not Moskow ML  
specific, that's by SML specification.

Just to underline a modeling language which help to forget about  
somethings, is not to be confused with a badly designed language.

> 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
I could not understand that point.

> 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.
I don't remember if I already told you (I feel I remember I did, but I may  
be wrong), but there is a plan to refine SML specifications.  
Unfortunately, as this one is not famous enough, too few people contribute  
ideas. This is still the best base I believe, due to the amount of work  
already done for that language (proved soundness and some experienced  
users with worthy comments).

> 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?
Well, I guess they “use only one for everything” :D

> The situation is worsened by overloading ASCII
Hum, Unicode phobia again.

> symbols, which according to Australian studies does not seem
> to help newcomers understand source text.
At least not me, so I can believe it.

> (Which, incidentally,
> is an argument against Ada's X(42) meaning both array component
> and call.)
No, that's not the same, because array access is a kind of function :-P .  
While that said, this would be easy enough to wrap array access in a  
function when one want the source to be independent of whether Foo is  
defined as an array or a function. This feature is from time to time, even  
promoted as a good feature of Ada (array access using the same syntax as  
function invocation)

> Concurrency.  ATS does address concurreny---with POSIX threads
> and such. Well, that's at least something. Or maybe not?
I am tempted to say “not as clean as Ada task, probably”, that's a good  
point to notice about ATS, but this is not really due to the ability of  
the language to hide feature X which is not relevant at stage Y.

> 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 ?
What is the question precisely ? I am not sure I've understood the  
question.

> 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.
When you say “as it is actually done, and supported”, do you suggest there  
could a good way to do ?

> The pattern,
> whether employed in language design or in programming, will generate
> insecure software and entail costly repair.
What about the example precisions I provided above in this message ?

-- 
“Syntactic sugar causes cancer of the semi-colons.”  [Epigrams on  
Programming — Alan J. — P. Yale University]
“Structured Programming supports the law of the excluded muddle.” [Idem]
Java: Write once, Never revisit