Re: How come Ada isn't more popular?

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

Georg Bauhaus <bauhaus@futureapps.de> writes:

> On Fri, 2007-02-02 at 00:40 +0100, Markus E Leypold wrote:
>> 
>> 
>> Georg Bauhaus <bauhaus@futureapps.de> 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 fuck-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.

Bullshit, 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