Re: How come Ada isn't more popular?

[Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de>]

Georg Bauhaus <bauhaus@futureapps.de> writes:

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

I wonder why one wouldn't just use Monads in most cases?

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


IMHO: no. Of course every functional interpreter / VM runs in an
imperative world: After all the past is really lost, that is,
destroyed. The question is how to maintain the (useful) functional
illusion when interacting with systems that can only be updated
destructively (e.g. the world). The IO Monad and its relatives are the answer.

But those Monads are not just an imperative kludge at the top of a
functional language as number of people seem to think. A Monad is a
beautiful thing. It contains only functions and rules to compose
functions and as such is purely functional. The typing just happens to
be arranged in a way the every world value can only be passed once to
a function and never be bound to an identifier. Thus it looks like
imperative programming but it is purely function -- or to put it
differently: The type systems restricts program construction to a
subset of the full functional language that is isomorphic to some
imperative language.


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

I think I can say. I've written and deployed programs in Ada, C, C++,
Perl and OCaml (among others). And I've played around with Haskell. I
think I'm more productive with FP than with C and Ada. I don't say
this to denigrate Ada: But I often do ad-hoc programming driven by
what works at the moment. What really appeals to me under those
circumstances is the way I can 'morph' working OCaml programs into
other equivalent OCaml programs. What also appeals to me (that is not
a property of FP per se, though Haskell, OCaml, most Schemes, have it)
is the ability to interact with the code (modules, libraries) I've
written in a command line to immediately test the results of changes
(have I broken anything just 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.

Recursion is the least of those reasons. What is IMHO more important
is, that you start not to think about mutating variables but producing
new values from give ones (a slight shift in perspective, but with
real impact at the long run).


>>  I refuse
>> to discuss merits of languages ot a micro level like:
>
> The "micro" level is the level of production, change, and correction.

I think you just did that at least one level too far down. Defining
'inc' or stuff like this doesn't give you any insight into functional
programming. I'm at a loss, though, to teach or tell you what to do to
get that insight. As you have noticed, FP appeals to
mathematicians. I'Ve mathematical background and I've some wildly
different pasts, but one of them was concerned with formal
specification. FP just came naturally to me: It mirrors the way I
think about a problem and about the solution to problems. The rest is
optimization: Eliminating double evaluations or even mutating
variables if that is needed for efficiency. But the first draft is
functional and stays the point of reference.

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

I fear your full of preconceptions. It's different from what you do in
Ada (or whatever your favourite imperative language is), so it must be
wrong or there must be something missing.

As an FP advocate, I suggest, that the things not written down, are
not necessary. So those "savings" you address as a defect are actually
a chance. 

But YMMV. As I said: I'm not in the business of convincing people WRT
FP. You already indicated that you would not accept the typical
reasoning of an FP protagonist. I can't offer you something different:
It's shorter, I can see the problem clearer, I can leave out redundant
information and so on.

Listening to you justifying that every, every variable must be
declared with type and all, one wonders hoe mathematics itself ever
could live without type declarations. But if

   Let V be a vectorspace. (* defining a name and its type *)

then

   Let v \n V

is just enough to know v is a vector. Saying

   Let v: Vector with v \ V.

is just superfluous. The same principle applies here: The type, what
the symbol is and in which context it is embedded, in which operations
it can occur, can be inferred. No need to declare more.

The same principle applies in FP. I fear it won't convince you.


> It's also typical math style: what is "obvious" to the insider
> needs not be said. What is "obviously" a complete expression

You can also hide what you want to express under a lot of superfluous
drivel (type declarations that can be inferred or at the worst be
queried from the interactive system). FP has set the cut off at a
different point than Ada. Question: Was that necessarily wrong? It
fits me. Does that make be a worse programmer / designer / software
engineer / mathematician? I don't think so.

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

I fear that hardly happens to me in OCaml. Partly because I compile
often and develop code over a number of intermediate scaffolding
stages which all type check properly. BTW: I had to use the same
approach with Ada, since in the presence of overloading and tagged
types the error messages can be become quit misleading, at least with
Gnat.

> 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

You know, I rather use OCaml for practical reasons (I like the object
system). But my experience is that it is the beginners that are most
obsessed with the "broken syntax". Related to that are the repeating
attempts on c.l.f. or c.l.l to suggest a new syntax surface for Lisp
"without all so parenthesis", implying that would hugely further the
proliferation of Lisp. There is, I think, already a c.l.l FAQ for
this. Though the attempts to reform ML syntax happen less often, they
happen and I count them under the same heading as those Lisp reform
attempts.

I think it would be rather simple to design a pascalish language whose
semantics is just declared by transformation to ML. I was tempted some
times to do it myself. But really: What would that buy me? Investing
the same time into understanding more ML / OCaml / Haskell will earn
me much more.

> that even Andrew Appel has added a few paragraphs to his Critique
> explaining what parts of ML should really be dumped and replaced.


Let me quote from the abstract of that paper:

   Standard ML is an excellent language for many kinds of
   programming. It is safe, efficient, suitably abstract and
   concise. There are many aspects of the language that work
   well. However, nothing is perfect: Standard ML has a few
   shortcomings. In some cases there are obvious solutions, and in
   other cases further research is required.

So we are talking about somebody intimately acquainted with the
language and the research on that language, striving for an
improvement. Talking that as ground (as a mere novice!) to say: "Nah,
that language is terrible, let's look for something different, at
least not start with this" strikes me as daring, even blind.

I suggest you really read the paper you quoted: He has some nice
things to say about the necessity of GC and the people who don't like
the "bizarre syntax" of ML. At the end of that paragraph he says: "But
in general, don't we have better things to argue about than syntax?".

Duh!

Actually the paper is a good defense why one should use an FP (or
something very similar) EXCEPT he/she explicitly has different
requirements.

Your approach seems to be more the Olde FORTRAN Programmer's approache:
I can do it in [...] so why must I use/learn another language.

I fortunately have learned FP at a time when I could see it as fun,
instead of having to defend myself against having to learn it. On the
other side I'm one of the perverts that sit down in a quiet hour and
write down mathematical proofs just for the joy of it. (Proves your
hypothesis about mathematicians and FP, probably.)

> This costs time and money.

Well -- every legacy feature does. Tell me, Ada has none :-).

Regards -- Markus