From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,21960280f1d61e84 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII Newsgroups: comp.lang.ada Subject: Re: How come Ada isn't more popular? References: <1169531612.200010.153120@38g2000cwa.googlegroups.com> <1mahvxskejxe1$.tx7bjdqyo2oj$.dlg@40tude.net> <2tfy9vgph3.fsf@hod.lan.m-e-leypold.de> <1g7m33bys8v4p.6p9cpsh3k031$.dlg@40tude.net> <14hm72xd3b0bq$.axktv523vay8$.dlg@40tude.net> <4zwt33xm4b.fsf@hod.lan.m-e-leypold.de> <1j7neot6h1udi$.14vp2aos6z9l8.dlg@40tude.net> <1170347180.14376.104.camel@localhost.localdomain> <1170363233.23845.118.camel@localhost.localdomain> <1170521693.6067.214.camel@localhost.localdomain> From: Markus E Leypold Organization: N/A Date: Sat, 03 Feb 2007 21:06:59 +0100 Message-ID: User-Agent: Some cool user agent (SCUG) Cancel-Lock: sha1:YLaNh34LTPAQlmp7ybUrCSb3GJs= MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit NNTP-Posting-Host: 88.72.212.247 X-Trace: news.arcor-ip.de 1170532922 88.72.212.247 (3 Feb 2007 21:02:02 +0200) X-Complaints-To: abuse@arcor-ip.de Path: g2news2.google.com!news1.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor-ip.de!news.arcor-ip.de!not-for-mail Xref: g2news2.google.com comp.lang.ada:8918 Date: 2007-02-03T21:06:59+01:00 List-Id: Georg Bauhaus writes: > On Fri, 2007-02-02 at 00:40 +0100, Markus E Leypold wrote: >> >> >> Georg Bauhaus 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 . 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