Re: How come Ada isn't more popular?


Georg Bauhaus <bauhaus@xxxxxxxxxxxxx> writes:

On Fri, 2007-02-02 at 00:40 +0100, Markus E Leypold wrote:


Georg Bauhaus <bauhaus@xxxxxxxxxxxxx> writes:

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?

You wouldn't just use Haskell and monads for at least two reasons:

- used in a natural way, Haskell equations (incl. monads) still
turn out to be comparatively slow. See Darcs (I am a Darcs user).

Darcs is slow because it partly uses algorithms with O(n^k) with big
k's or even exponential run time. It's not a I/O or monad problem as I
have understood.

- control over what is going to happen at what time is easier using
a systems programming language.

Sigh. I can't convince you here. There is no reason to assume the
necessary level of control cannot be achieved with a language like
Haskel. Given it has to me achieved at all.

But I also notice a loss of context. You were talking about fusions
and I said "I wonder why one wouldn't just use Monads in most
cases?". You way to quote that back on me somehow mangles that
context.

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.

It will be most interesting to learn the specifics of what makes
you more productive using OCaml instead of Ada etc, language-wise.

How do I know? I just obeerve it, that it is so and I can of course
speculate why that is so. But what I experience is not a controlled
experiment and I will be met with responses that tell me, it can't be
that this is the reason or even that I'm more productive, because
<theory of your choice>.

My to points:

- The ML-typesystem (specifically the OCaml way to integrate
objects) is safe w/o forcing you to through contorsion in the more
abstract cases as. i.e. Java or Ada in their way to implement
classes. This seems to be an effect how classes work together and
see each other and cannot be seen with examples involving only 1
or 2 classes.

- GC really is a boon if objects recursively refer to each other (A
calls be an vice versa). Their life cycle is somehow coupled and
there seems to be no general (!) way on deciding who needs to
deallocate whom.

- What I like very much is type inference if used right. Parametric
polymorphism allows be to concentrate on the aspect at hand and
not to have to concern myself with properties of data that are not
relevant for the algorithm.

- It's really easy to refacto functional programs incrementally by
morphing over a number of correct intermediate stages.


A more important reason not to ignore functional programming
is [... ] Recursion

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

Yes, you replace thinking about updates to a variable by
thinking about values passed, and their relations.

About data flow, to be correct.

Now unless you write a straight line program, this won't
work without recursion :-)

Yes, but recursion is not the big eye opener here. You said "A more
important reason not to ignore functional programming is [... ]
Recursion". I say: Recursion is more at the surface here, but hardly
the big difference to imperative languages (which all can recur
:-). It's more at the surface, though.

Thinking about function values and their combinations
like map + filter is another good thing to learn (and use).

I've been starting to write a library like this in and for
Ada. Unfortunately I'm missing time and motivation to continue.

OTOH, FP style is sometimes just assignment in disguise. It hides
the variable as a parameter (and relies on TCElimination) in a
sense.

Man, it's not assignment that is BAD. It's just that the programmer
shouldn't program it and should keep to a language in which equational
reasoning is possible. The compiler on the other side is allowed to
optimize what it wants.


I don't think this is always easier to follow:

function Sum(L: Cursor; Variable: Integer := Initial_value)
return Integer is
begin
if Has_Element(Cursor) then
return Sum(Next(L), Variable + Element(L));
else
return Variable;
end if;
end Sum;

function Sum(L: Cursor) return Integer is
Variable: Integer := Initial_Value;
begin
while Has_Element(L) loop
Variable := Variable + Element(L);
Next(L);
end loop;
return Variable;
end Sum;

(Yes, a true FP Sum function is composed, taking a binop as a parameter
for folding and you make it a base-case-step-macro in Lisp ;-)

Yes, a really terrible example: Pseudo FP with Ada syntax. I'm not
surprised you find it difficult to follow.

sum = fold (+) 1

How's that? And that really summarizes what a functional programmers
knows and wants to know about linear iteration with a state over some
linear collection of thingies. Another example: Revert a list.

rev = fold (fun x xs -> x::xs) []

And now removing all element with certain properties (p) from a list

remove_rev p = fold (fun x xs -> if (p x) then xs else x::xs) []

remove p l = rev (remove_rev p l)

Read fold as "iterate and do the following ... starting with ..." and
you got the essence.


I still think that it is just a bit more difficult to follow the
first Sum.

Because of the atrocious syntax: Not really suitable for the purpose.

If you want to know how Sum is going to arrive at a result then you
have to follow the history of Variable through a series of function
calls with a series of changing arguments (the induction step).

"How do you know how Sum is going to arrive at a result when you have
to follow the history of a variable through a series of iterations
with a series of changing state variables"

To answer you question: Because most definitions of data
transformations a recursive in nature: Do a small step, the do the
rest. E.g. I don't see another way to work on trees (like XML
documents) without risking major ***-ups.

In the second Sum you see the history of Variable without following
the mechanics of a function call and it is still just one place
where Variable is modified. It's less hidden behind the "function
call screen".
Still I much prefer the recursive, nested narrowing
function in my Binary_Search -- even though the loop
based variant is faster with some Ada compilers :-)

It's certainly easier to see that the first Sum matches
a primitive recursive function if and when this is important.

No.


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

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

As you have noticed, FP appeals to
mathematicians.

Yes, FP has a mathematical appeal. However, time and space
are not usually intrinsic parts of mathematical functions. This is

No? What about State (t) = ...? Are mathematical functions somehow
against nature? Will my machine time shift or desintegrate when I
write pure functions?

A no to all that questions. I hardly see why I should think about time
and space _all the time_. It's the compilers job to make something
from it and it does a good job of this. Data is evaluated when needed
(call by need ...). Not when passed and perhaps not needed. I'd even
venture there are enough (not IO bound) problems where eager language
evaluate much too many data items which are, finally not needed at
all. Functional is basically about need: When data is needed, it is
evaluated.

And when I need to have interaction with space and time (i.e. the
outside world) and not just live in the data sphere, the IO monad
comes to the rescue.

Forgive me, I'm not one to cry FUD early, but your permanent
assertions that time and space complexity are so unmanageable in FP
are simply FUD and they reflect the state of FUD some 20 years ago. I
think there is even a paper of Wadler on that.

what I am trying to point out: a computer program operates in time
and space, it is not a mapping between two sets of values,
even though you can interpret the operating program this way.

Yes, it'd not even manipulating numbers but levels voltage and
strength of current. I'm not programing with the voltmeter though --
we have stopped to do that in the fifties. This is progress. It's
called abstraction.

A "functional solution" is still very helpful as a reference,
just like you said.

Not only that, but I won't be able to convince you. I'm no purist,
though. We started with talking about the type system and I'm not
averse to writing imperative procedures in ocaml and using them
together with a functional library.

For example, a functional solution helps me stay
sane maintaining one of my longer Perl programs that takes about 35 min
on average to compute a number of rankings from some larger database
tables. :) But sometimes a functional solution is only a starting
point, a necessary precondition.

Sometimes ... -- But therefore FP is bad all the time because it is
not somehow tied to time and space? I'm starting to become confused.

It provides guidance when writing the real thing.

Only that the unreal thing works perfectly most of the time. Why
should I rewrite?

At other times, a functional program is just fine, provided
the author follows the usual conventions: Don't leave out that
much, it won't hurt if you say what you mean.


I'Ve mathematical background [...]. FP just came naturally to me:
It mirrors the way I
think about a problem and about the solution to problems.


For example, a Haskell program can be an executable specification.

A Haskell program is program, not a spec. How can people confuse that?
A spec often has predicates that simply cannot be computed at all or
only at forbidding costs.

Unfortunately, this may not be good enough because what you call the
"rest" is *not* optimization.

?? rest ??

It is meeting the requirements, even when these requirements are
"Start no sooner than 22:00h, be ready before 23:00h."

Time and space are intrinsic parts of a solution.

Nonsense. Intrinsic? In the sense if I don't think always about it, my
functional program will not start when I tell it, but some time
araound last easter? Man, that are not even real problem you're
injuring up here! Apart from the fact that Monads provide the handling
you're trying to deny that it exists. q

If the problem
specification includes time and space,

That is, if we are talking about a real time problem. Fine. As I
repeatedly said, most of the things I'm talking about are not real
time problems. I simply refuse to throw away a suitable tool and
exchange it against an unsuitable one, simply because some problem
sets cannot (perhaps) be dealt with by the useful tool.

All arguments you gave can as well be applied to not using a compiled
language, but using assembler. "Sometimes you don't knoe about the
instractions the compiler generates. If the problem specification
includes time and space, a complete solution must [...] -- let's all
use assembler where we have full control, all the time, also in
ordinary application prgramming".

a complete solution must
in effect provide time and space values as well. (Make self-referential
considerations WRT time and space when computing, so to speak.)

The meaning of the word "optimization" is, I think,
to improve existing solutions so they run faster, consume
less resources, are easier to understand, etc.
Optimization does *not* mean to turn something that isn't a solution
into a solution.

This is what mathematicians refuse to see, as far as I can tell.

Well - how can I refute that? There is so much work (by
mathematicians) on specifying real time algorithms and giving real
time assureances) that your across-the-board accusation strikes me as
simply unjustified. There has also been work on realtime systems and
ML and furthermore only a small fraction of applications and problems
are real time oriented. Functional computation doesn't happen outside
of space and time and the space and time behaviour is mostly well
understood.

So I fail to see how FP should be bad because it doesn't refer to
space and time or doesn't specify sequencing of operations outside of
Monads or effect systems. You know, I don't see a time variable in C
or Ada either and as far as sequencing goes: You know that modern
compilers reorder the operations to achieve optimization?

The stigmatize time and space as being just "optimization" issues.

? You must be dreaming. Perhaps your confusion stems from that you mix
up mathematicians, mathematically inclined software engineers and
functional programmers. I personally I'm wuite glad that, say, linear
algebra has not time+space component in it. But what has that to do
with our problem?

Or care to alaborate to which people you refer when you say
"mathematicians"?

They are not. In programming, a function is more than an equation
over some field that excludes time and space.

You mix up functions (a mathematical construct) and procedures (a
specification of an operation or computation to be performed by suitable computing
machine).

Functional programming also specifies operations (not mathematical
functions) but the intresting part is, that it does so in a more
abstract way: It just says what has to be delivered when needed and
(in the lazy case) leaves the rest to the compiler / runtime system.

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.

Why would I be writing programs in OCaml, then?

Yes, I wonder, indeed.

As an FP advocate, I suggest, that the things not written down, are
not necessary.

FP error messages get better in the presence of explicit types.

At the right places. Not at all places. It's that difference evrything
is about.

Redundant semicolons can help the functional compilers a lot
in figuring out where there is an error in the program text.

No. Redundant semicolons very probably make your ML/OCaml compiler
barf at you.

Not necessary?

??

Or are FP programmers of the compiler writer type who hardly
need a robust language?

FUD. (a) what is a "robust" language. (b) what has it to do with
semicolons and (c) why don't I have the problem to understand my
compilers error messages?

I really wonder about your experiences.


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.


That's the point: it's you who sees clearly, you leave out what seems
redundant to you, etc.. But those other guys, trying to understand
your program, will have to repeat your arrival at a clear sight,
they will have to iterate the learning process that makes things
seem redundant to you, etc..

I wonder why you think, that Perl and Ada are readable and FP is not?

The usual answer I got when asking about this is, well, I need
educated colleagues with skills at about the same level as mine.
Sometimes that seemed just true, sometimes that's snobbish,
in some cases it has seemed to express pride. It has also been
an attempt of a programmer to make himself irreplaceable.

Bull***, man. What actually do you suggest? That I, I!, have to
program everything in e.g. C so that every other gonzo in the world
can understand all the programs I e.g. wrote for my use and
entertainment?

George, I give up on you. You don't understand -> it's my problem and
you don't give me enough clues to get you, well, clued in. You seem to
have had some real bad experiences with mathematicians and functional
programs. I can't help you there. FP, perhaps, is not for you. I'll
always be happy to answer specific questions, though.

That's the point: it's you who sees clearly, you leave out what seems
redundant to you, etc.. But those other guys, trying to understand
your program, will have to repeat your arrival at a clear sight,

But I can't answer diatribe of this kind, expect with "I don't have
that problem, nobody I know of has it etc., I hardly have problems
reading other peoples OCaml programs etc...".



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

Mathematicians use explanatory sentences and bibliographic references
as a replacement for declarations. So they do declare.


Well, we can suppose, that someon trying to understand a program in
Haskell or OCaml or even Perl has read parts of the reference manual,
can we?

Only the declarations are semi-formal in many cases like you show
in your example. After "Let V be a vectorspace", V is declared,
is in scope, and references to V will just name V of type vectorspace.


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

Where FP authors follow the conventions of good style,
they list a function's type, or they add a semi-formal comment,

No, sorry, they don't, They do that for key functions, not for
functions with the status of lemmata. They do it for interfaces. And
you know what: The language requires it in interfaces,

or both.

Why would they do that if these things are redundant
and should therefore be left out?

This IS childish. Also because it depends on your made-up definition
of good style in FP, which is, incidentally, not true.

You quoted Appels ML critique -- have you actually read it?


FP has set the cut off at a
different point than Ada. Question: Was that necessarily wrong?

No, not wrong. It just has consequences to leave things out.

Just some paragraps ago you said, good style doesn't leave that things
out. Necessarily leaving the out is bad style: So bad. Seems to me,
you said wrong.


It
fits me. Does that make be a worse programmer / designer / software
engineer / mathematician? I don't think so.

Imagine an engineer writing programs and documenting his
assumptions even though he thinks they are redundant because
they can be inferred from some context. Worse or better? Why?

What has that to do with type inference?


Imagine a script author who has to get some data laundry job
done. Would he/she be well advised to write a program that
can be reused, with all bells and whistles, good types, OO
encapsulation?

Or just use a bunch of lists, tables, and
regular expressions?

(What's the probability of a once-program
becoming an n-times-program, anyway, in reality?)


What has that to do with type inference?


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.

I think it's really not important what happens to you and me here.

But your anecdotal evidence is?

What is important is what happens to the amount of available
money to pay us until we arrive at an error-free solution.

Please, you use your tools, and I'll use mine.

How much time is spent by the programmers when correcting
mistakes, and how do OCaml and Ada compare in this case in
typical settings?

How do they?

The error messages of the Erlang system can be even
more obscure. Some of them are printed at run time.
Sometimes there isn't a message at all ... Still, the language
is somewhat minimal and Erlang can help solve some problems
quickly provided the Erlang programmer knows the language, the
libraries, and the system and its quirks.

Good idea. If you need an argument, pull it from another functional
language, (anecdotal evidence again) and pose it as typical. So all
faunctional langauges / programming systems have to hjustfy the
weaknesses of any of them.

If you write Erlang programs, you *must* be able to say,
"I fear that hardly happens to me in" Erlang. Otherwise
you will be lost tackling errors you don't understand
because there is comparatively little "redundant" information
in Erlang programs.

So saying this is an invalid argument. Unfortunately that also applies to

"I find error messages of the Erlang system even be more obsure".

Not the I, I have been adding here.



the presence of overloading and tagged
types the error messages can be become quit misleading, at least with
Gnat.

It can be.


But my experience is that it is the beginners that are most
obsessed with the "broken syntax".

Of course the beginners complain! Just like when someone switches
from permissive C to unforgiving Ada. But is't not the syntax
of Ada that seems to cause difficulties.

So? So your complaints about ML syntax become a valid and important argument?

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.

I know, and it has taken me some time an effort to make
some proponents of Lisp syntax see the problem in the first place.

(Usual suggestions: If you run into "syntax error at end
of file", just fire up your Lisp system's editor, some function
will look "skewed" and point you near to where a ')' is missing.
Well...)

Yes, well? So what? The Lispers seem not to have the problem you
have. What does that tell you? Probably: Typical FP advocates, they
just pretend that is not a problem and leave all other people outside
in the cold rain? Tell me; What does that tell you about your approach
to a new language or programming system? I got the impression now,
that you try to retrofit your Ada / Perl / C / whatever experience to
the new system and that you're peeved of than, if that doesn't work.

I notice we have been departed from teh discussion of technical
properties of languages and the possible implications for constructing
programs and have strayed in the realm of pure taste - Like "I don't
have the problem -- typical, that you would deny it" and bad analogies
"Imagine an engineer, who ...".

Unfortunately I don't feel qualified and I'm not intrested to discuss
believes and tastes of that kind especially since have reached some kind of deadlock.

So I suggest, we either shift that thread to a functional forum, group
or list or I'll at least stop participating in this particular sub
thread. It seems to be wast of time, since I really can't change or
influence your point of view.

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.

You cannot take pride in having mastered a syntax that is no
challenge. :-)

What is that supposed to mean?


But really: What would that buy me? Investing
the same time into understanding more ML / OCaml / Haskell will earn
me much more.


Let me quote from the abstract of that paper:

...
So we are talking about somebody intimately acquainted with the
language and the research on that language, striving for an
improvement.

That's why I quoted the paper. It does explain why ML is important.
And that too little attention has been given to syntax.

Better reread that paragraph.



I suggest you really read the paper you quoted:

I did, I usually read the papers I quote before I argue ;-)

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

Syntax is structuring our communication.

We have important things to achieve, and just ignoring syntax
won't make us more effective.

So be free to continue arguing about syntax. I more agree with Appel
on that subject.

But since we are starting to throw
papers at each other, here is another, more or less empirical one,
talking about programmers discussing(!) irrelevant syntax:)


"Of the pretense (syntax is irrelevant) and the actual reaction
(syntax matters), the one to be believed is the actual reaction.
Not that haggling over parentheses is very productive, but
unsatisfactory syntax usually reflects deeper problems, often
semantic ones: form betrays contents.

"Experienced programmers, so the argument goes,
will never make the error. In fact they make it often.
A recent review of the BSD operating system source..."
-- Betrand Meyer, Principles of language design and evolution, §8

The last sentence is about '=' in C comparisons. '=' has caused a
problem in ML, too. Hm, perhaps everything coming out of Bell
Labs must continue Bell Labs traditions. SNOBOL4 has '=', C has
it so C++ has it, Aleph has it, Limbo, too IIRC. So maybe ML has
had to have the '=' trouble maker, too.

So C has problem with "=" and "==", which of course makes your
complaints about ML syntax valid...?


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.

Not at all. What makes you think so?

I think there is a bit of context missing here.

This costs time and money.

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

In the case of OCaml, there is at least camlp4.

So?

I understand nobody
seems to want the revised syntax? Not cool? Herd instinct?

No. Keyword is maintainability and tool support (this starts with
emacs modes. Tuareg + traditional syntax buys you more than revised
syntax.

Fear of change? "No, it's not necessary, we have learn-ed ouR
working in-group syntax."

I find that rather typical that you insinuate elitist motivation
here. Of course I can't help if you experience the world like that.

I only wish someone could win the lottery and have some language
designers work on the formal principles of sound syntax for industry
programming languages.


Instead, legacy syntax is reintroduced again and again, by
the same people who argue it doesn't matter because they have
finally learned to work around the broken syntax.

So why not again use the broken syntax? Professional

Let me sing that again: Tool support, existing code, existing know how
and training.

programmers get bitten by the syntax bugs again and still
continue to claim this isn't important...


A few weeks ago a colleague explained he always writes

if (expr == false)

{

because a '!' can be hard to see. I told him he could always use

if (!!!expr)
{

...


Which langauge is that supposed to be? It ain't C, this much is
sure. And what does that prove?

Regards -- Markus
.