Re: How come Ada isn't more popular?

[Georg Bauhaus <bauhaus@futureapps.de>]

On Thu, 2007-02-01 at 18:36 +0100, Markus E Leypold wrote:
> Georg Bauhaus <bauhaus@futureapps.de> writes:
> 
> > On Thu, 2007-02-01 at 15:22 +0100, Dmitry A. Kazakov wrote:
> >> On Wed, 31 Jan 2007 16:16:20 +0100, Markus E Leypold wrote:
> >
> >> > I notice, that nobody that actually has tried
> >> > FP doubts the superiority of the style in general (they are bitching
> >> > about efficiency, sometimes, and availability of libraries, mor
> >> > often).
> >
> > FP is superior to what? 
> 
> Superior to not having "full" closures. WRT to abstracting over parts
> of an algorithm / solution / component. The full context of this
> comment of mine was:
> 
> > > >> If yout have only downward scopes for "closures" and memory allocation
> > > >> this will, finally, interact badly with the fact that "implicit
> > > >> (i.e. static type safe) casting" of classes is also only possible
> > > >> downwards. My impression is, that all these things together rule out
> > > >> some useful designs, that would otherwise possible. Or to say it
> > > >> differenty: Object orientation w/o indeterminable scopes, upward
> > > >> closures and GC doesn't work well. Some abstractions cannot be
> > > >> implemented.
> 
> > > > Umm, I cannot tell. 
> 
> > > I think I can tell, but the discussion on this topic (what is
> > > functional programming good for) does still rage on c.l.f and the
> > > relevant mailing lists. I notice, that nobody that actually has tried
> > > FP doubts the superiority of the style in general (they are bitching
> > > about efficiency, sometimes, and availability of libraries, mor
> > > often).
> 
> 
> 
> > I'm saying this having had some fun writing
> > small OCaml command line tools. There are many good
> > libraries. And some things are just easy to write.
> >
> > Hm. The compiler error message are as helpful as you
> > would expect from inference machines (on a par with Hugs or C++
> > template error messages). GHC has been improved in this regard.
> 
> >
> > But how would you know that those who have tried FP don't doubt the
> > superiority of the style? 
> 
> Admittedly, I don't. It's only difficult to dicuss the question wether
> one would want to have e.g. closures, with people who haven't tried
> it. As I wrote elsewhere: All common programming languages are Turing
> complet, so equivalent. There is nothing that can be done in one that
> could not be done in the other -- in principle. So there is nothing
> like a proof "you cannot do X in language L" or "without feature
> F". There is just how "easy" it is to express things and this is, to
> an extend highly subjective.
> 
> > Any statistics? What does "in general" mean here?
> 
> My private head count. OK. I haven't proved it. 
> 
> > Are they really thinking that the inferior crowd doesn't write
> > recursive functions?
> 
> > Well, perhaps that is true... 
> 
> Well, see, ..
> 
> 
> > GCC does try to
> > eliminate tail calls, though, so maybe we can see a shift from
> > loops and counter manipulation towards recursive subprograms some day.
> > ;-)
> 
> ... as you see yourself, the language has to provide some support to
> make that efficient as a general technique.
> 
> > One of the great new pieces of Ada 2007 is Ada.Containers in my view
> > precisely because it permits what is taken for granted with FP or
> > with scripting languages: lists, tables, and sets, and ways to
> 
> Yes, but in an imperative way. Still, it's progress, I completely
> agree.
> 
> > use or write generic algorithms involving all of them.
> 
> > There isn't a lot of curry in there, but much else.
> 
> Currying is somewhat overrated, but's it's hardly the essence of FP.
> 
> 
> > To me, many of the FP advocates seem to be mathematicians. If you
> 
> I studied physics when I were young ... 
> 
> > look closely, two phenomena appear frequently in e.g. OCaml programs:
> >
> > (1) Either they use functions assembly language(!!!),
> 
> What do you mean by that?
> 
> > (2) or they use reference types and assignments almost exclusively.
> 
> Don't know who "they" is here. Certainly not me nor Richard Bird nor
> the Haskell crowd in general.
> 
> Yes, Ocaml, because of it's imperative elements has some potential to
> get abused. Writing reusable components though, is, IMHO, done by
> embracing a functional style.
> 
> 
> > -> (1) can be attributed to the programmer being a mathematician:
> > function assembly is a game in logic. Might be fun. Is it easy?
> 
> It's rumored to be accessible to certain optimization techniques. I
> assume you mean the so called "point free style"?

Yes, though whether or not there a points and parentheses is not
important.

> Side effect free FP

This is a plus. However, if you mark the variables involved
in creating side effects, as is done in SPARK, you can match
the result with a synthesized pure function, I think.
A reasoning function that takes the global variable as input.


>   let foo x y z =
> 
>       let old = (foo x y z) 
>       and opt = (foo_opt x y z) 
>       in 
>          if not (old == opt) then raise (Testing_error "foo_opt");
>          opt
> 
> 
> This technique is too expensive and cumbersome in imperative
> programming (yes, I tried it, it sucks, even for simple stuff).

?

   function foo(x, y, z: natural) return Integer is
        old: integer renames foo_old(x, y, z);
        opt: integer renames foo_opt(x, y, z);
      begin
        if not (old = opt) then raise Testing_error with "foo_opt"; end if;
        return opt;
      end;


> Programming, IMO, is not, manipulating the machine, but processing
> data. 

Well, and what is processing data?


> > So why doesn't someone tell the FP people to advocate a theory of
> > functions that
> >
> > (a) match empirical comput*ers* better than they match some model
> > of comput*ation*.
> 
> What's your problem with that? I actually don't even see the problem
> you're trying to address. Care to elaborate?  And shall we shift that
> thread to c.l.f :-)). It's a bit quiet there at the moment.

de.c.l.f is probably even more silent, but there are some
important references to Ada here: the Ada language is about computers,
given all the systems programming stuff, all the rules about
what is happening and when, representation, order of elaboration,
addressing multiprocessor systems, time types, etc. etc..

OTOH, there is little reasoning about equations in the vicinity of
Ada, is there? And what _is_ reasoning about equations? It is us
at work. (When we are "computers" in the old sense of the word.)
We *operate* when we reason, even when we reason about equations,
we try to *follow* what is going on. There is always one of a number
of possible *orders* of "evaluation" in

foo r = pi * d
  where pi = 3.14159
        d = 2 * r

no matter whether we bother to concentrate on the where clause first
or start with concentrating on the main clause of the equation etc..

I hear the comput*ing* scientist and the Haskell fan say:
--- But this is the important thing in a equation, you needn't
    worry!
Then I say, 
--- But computers have 1 or more sequential processors, and one thing
    happens after another. There are *operations* inside a computer.
    They take time and space, and they have effects. I must coordinate
    these effects.
I hear,
--- Just use strict if you must! Or monads. Why do you want to reason
    about what is going on, anyway?
And here the comput*er* plays its part.
--- Because I don't have the luxury of abstracting time away. And not
    space either. If you can follow computing steps at leisure, fine.
    If you are done once you have declared the timeless static
    connection between two sets of values, and call it a function,
    fine. I'm not done yet.

The next answer I will get is, well, try fold_left, or fold_right,
depending on the situation, or try this finding, etc., we don't know
exactly what is going on but it usually suffices. And the result is
correct, provided it can be computed on this machine.
  Ada.Containers, or the STL are more helpful in this regard because
they allow some amount of predictability of runtime *behavior*.
That an input value corresponds to an output value of some function
is a necessary but not a sufficient precondition. It is not important
*that* it will be computed, but *how* it will be computed. Sad but
true. And not for reasons of optimization, but because time and
space are almost always an essential parts of a problem specification.

Time and space are not normally considered the hall mark
of equational reasoning in FP. I think it is safe to say that
when you write a real-time application in Ada, you will be
thinking about time and space all the time, and you want this
task to be straight forward. As few implicit things as possible.

> 
> > (b) are no harder to analyze WRT O(?) than plain old procedures?
> 
> They aren't.

I meant that the behavior of lazy programs is harder to analyze,
or has there been an advance recently?

> > Wait, Haskell is trying (a) by capturing imperative statements
> > in monads. The chapter on fusions in Bird's Haskell book lets me
> > think that you add simplicity by mixing FP with imperative style
> > when memory or speed are a consideration.
> 
> No, you don't add simplicity.

I meant, if you write some of the I/O parts in a systems programming
language like Ada, you increase simplicity and efficiency of the
resulting program when compared to an FP only program that uses
fusions.  I think that Ada *and* Haskell will make an interesting
combination on .NET.

>  Monads, IMO, are not
> imperative. They are a cute trick [...]
> that state [...]
> can be updated destructively .

Uh, I thought this very issue is what von Neumann style is about?
Hence what imperative is about.


> > How is this FP style superior, besides being brief and full of
> > assumptions?
> 
> Have your way: It's not. [...] be free to ignore FP.

I'm serious about this. I don't ignore FP. When I have to
make a change, when the module structure needs to be reworked, when
the program fails for some inputs, am I really more productive
using FP? I can't say right now.
  A more important reason not to ignore functional programming
is that it teaches a different programming style. Recursion
and its approach to iteration is well worth being studied,
as it helps simplifying some algorithms.

>  I refuse
> to discuss merits of languages ot a micro level like:

The "micro" level is the level of production, change, and correction.


> > How is this FP style superior, besides being brief and full of
> > assumptions?
> 
> That is not FP. That is, essentially, your style when interacting with
> OCaml and your problem.

FP is brief and full of assumption because they set out
to safely save the work of writing things down - technically.
It's also typical math style: what is "obvious" to the insider
needs not be said. What is "obviously" a complete expression
needs not be terminated. This leads to undecipherable error
messages when you forget to place one missing token to complete
an expression that is the last thing in a function definition.
This is part of the problem that is *made* my problem by a
functional language such as ML. ML's syntax is so terribly broken
that even Andrew Appel has added a few paragraphs to his Critique
explaining what parts of ML should really be dumped and replaced.

This costs time and money.