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-7-bit 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> From: Markus E Leypold Organization: N/A Date: Fri, 02 Feb 2007 00:40:23 +0100 Message-ID: User-Agent: Some cool user agent (SCUG) Cancel-Lock: sha1:trlMj3L+798dKVA/Mr1QF1YJBIw= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii NNTP-Posting-Host: 88.72.246.10 X-Trace: news.arcor-ip.de 1170372929 88.72.246.10 (2 Feb 2007 00:35:29 +0200) X-Complaints-To: abuse@arcor-ip.de Path: g2news2.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:8852 Date: 2007-02-02T00:40:23+01:00 List-Id: Georg Bauhaus 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