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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: "G.B." Newsgroups: comp.lang.ada Subject: Re: If not Ada, what else... Date: Tue, 28 Jul 2015 12:58:26 +0200 Organization: A noiseless patient Spider Message-ID: References: <06f8a6f9-d219-4d40-b9ac-8518e93839bd@googlegroups.com> <87y4io63jy.fsf@jester.gateway.sonic.net> <7a29d3e9-d1bd-4f4a-b1a6-14d3e1a83a4d@googlegroups.com> <87mvz36fen.fsf@jester.gateway.sonic.net> <2215b44f-8a89-47c6-a4c4-52b74d2dac45@googlegroups.com> <9e492c82-868d-43d3-a18a-38274400e337@googlegroups.com> <40184feb-4053-4ac3-8eaa-c3bd9cd8a77c@googlegroups.com> <10272577-945f-4682-85bc-8ad47f3653ae@googlegroups.com> <87si8i81k2.fsf@atmarama.net> <8076cbd0-2655-4c98-b70e-cb5f0c32e4ba@googlegroups.com> <87lhe0px07.fsf@jester.gateway.sonic.net> Reply-To: nonlegitur@futureapps.de Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Tue, 28 Jul 2015 10:56:53 +0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="b96887e80893c84a90c3007226ca0d1c"; logging-data="14555"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+j0lAz18hQR11k9nhuYiQfSwLEFF4kH1o=" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 In-Reply-To: <87lhe0px07.fsf@jester.gateway.sonic.net> Cancel-Lock: sha1:QbfNjSSm8K7H2rB95kSeh+bWGdw= Xref: news.eternal-september.org comp.lang.ada:27076 Date: 2015-07-28T12:58:26+02:00 List-Id: On 28.07.15 09:22, Paul Rubin wrote: > Georg Bauhaus writes: >> why would C, say, be better for prototyping than Ada? When would SETL, >> or Python, or BigEEMathSimPack be better suited? > > See: > > Haskell vs. Ada vs. C++ vs. Awk vs. ...: An Experiment in Software > Prototyping Productivity > > by Paul Hudak and Mark P. Jones > > http://web.cecs.pdx.edu/~apt/cs457_2005/hudak-jones.pdf O.K., so when the problem lends itself so well to equations of relation, as in this real world example of geometrical constraints, then Haskell is an inescapably natural choice, in particular for the programmer suitably skilled in mathematics. (I mean it.) Views seem to differ when the same approach (higher order function types) is used in drafting GUIs: following flows becomes as easy as interpreting the diagnostic output of C++'s functional template computation hitting an error. I find it a little unfortunate that much emphasis is put on notions such as "elegance" or "conciseness" and "almost like writing a paper" (and not a prototype? :), but that some features are just barely mentioned, like "prototyping support", which I thought would be rather interesting to know. There are mentions of the Prelude, though. Granted, when exploring a model of an algorithm in the abstract, what could be better than a concise, formal abstraction? (And not something for controlling a computer more directly, like Ada or C++?) Which could mean that SPARK is a surprisingly good prototyping language! Specifically, to the extent that provers will handle primitive recursive functions, to match Ada operations later. (Is that practical?) >> How is a prototype useful when the language used for prototyping >> tends to vaporize the Why-and-How of its choices and structure?) > > (...) It's like making a pencil sketch before starting an > oil painting. I do hope this process of producing a (executable) specification isn't as frequently doomed to become a production item by managerial decision to reuse as I have witnessed! The suggestion of Hudak & Jones (NB: WG members FP) may even support this view in spite of Bird's Chapter 7 (Efficiency, Fusions), or considering much use of "strict". (Line count up, complexity of code up, doubled effort through understanding and controlling evaluation, ...)