Re: How come Ada isn't more popular?

[Georg Bauhaus <bauhaus@futureapps.de>]

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? 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? Any statistics? What does "in general" mean
here?  Are they really thinking that the inferior crowd doesn't write
recursive functions? Well, perhaps that is true... 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.
;-)

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
use or write generic algorithms involving all of them.
There isn't a lot of curry in there, but much else.

To me, many of the FP advocates seem to be mathematicians. If you
look closely, two phenomena appear frequently in e.g. OCaml programs:

(1) Either they use functions assembly language(!!!),
(2) or they use reference types and assignments almost exclusively.

-> (1) can be attributed to the programmer being a mathematician:
function assembly is a game in logic. Might be fun. Is it easy?
What about review, changes, maintenance?

-> (2) is a strange thing: These are imperative programs, written
in some allegedly functional language, and they are written this way
because they will then run faster most of the time.
What would Peter Naur have to say about this von Neumann style?

Among FP advocates, there is always someone who just forces computers
to be abstracted into a function instead of considering what a
programmer MUST do and what most actual programming is all about:
manipulating the machine in operation, not manipulating some model of
functions.

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*.

(b) are no harder to analyze WRT O(?) than plain old procedures?

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.


> > BTW -- another argument _for_ a builtin list syntax.
> 
> Hey, Ada already has ()-brackets. Maybe our Unicode fans would propose
> special glyphs for )), ))), )))), ))))), )))))) etc. Is it what you mean as
> special syntax? (:-)) 

Actually, a syntax that is used in a theory book is
{left/right paren}{subscript i}.
The different lists of statements of an Ada program are marked using
more or less different pairs of brackets (if .. end if, loop .. end
loop, do .. end, ...).

What does a list syntax buy us if there is no argument pattern matching,
or no data structure pattern matching in Ada? Brevity?


> > One point is, that
> > the type fitting into a slot in a functor or as a paramter of a
> > procedure might well never have been defined explicitely but is a
> > result of type inference.
> 
> Why bother with types if you can infer them? I suppose, because you only
> think you can...

It is considered good Haskell style to list the function
type before the function. I like it being able to write OCaml code
that does the same:

let inc: int -> (int -> int) =
   fun k x ->
      x + k     (* (+) forces int anyway *)

Actually, to be more general and stylish, I could have written

# let inc binop increment arg = binop increment arg;;
val inc : ('a -> 'b -> 'c) -> 'a -> 'b -> 'c = <fun>

Hm. I wanted binop taking two 'as - the implementation might
change and require that binop be symmetric. When people
have used my inc with a binop taking different types,
they will have to change their programs too. Ouch.

So maybe I can think of some trick to make the inference
circuits assume binop takes two arguments of type 'a.
Or just write what I want and name the types!

How is this FP style superior, besides being brief and full of
assumptions?
Sure the function is a value that can be passed around freely,
and can be used in currying. OK. This is another technical
facility that is powerful.


generic
   type T is private;
   with function "+"(a, b: T) return T;
   increment: T;
function Inc(arg: T) return T;

function Inc(arg: T) return T is
begin
   return increment + arg;
end Inc;

Looks like more code, and I hear an FP advocate saying, "in FP,
you just ...". Any sentence that starts with "You just ..."
is suspicious :-)

Can I have this without generics, please, Dmitry? ;-)