[Haskell-cafe] A backhanded compliment and a dilemma

[Tobias Dammers]

Consider this: the most popular programming languages overall are
(arguably) PHP and Java, despite being almost half a century behind the
state of the art of programming language design in many ways. Ask yourself
why that is (and no, I haven't fully figured this one out myself either).

On Oct 20, 2016 5:22 AM, "Rahul Muttineni" <rahulmutt at gmail.com> wrote:

> You core problem has existed since 1994 :) It'd a bit disappointing that
> we've only made so much progress in the psychological perspective in 26
> years.
>
> Quoting [1], a study on prototyping software with different languages:
>
> One observer described the solution as “cute but not extensible”
>> (para-phrasing); this comment slipped its way into an initial draft of the
>> final report, which described the Haskell prototype as being “too cute for
>> its own good” (the phrase was later removed after objection by the first
>> author of this paper).
>> We mention these responses because they must be anticipated in the
>> future. If functional languages are to become more widely used, various
>> sociological and psychological barriers must be overcome. As a community we
>> should be aware of these barriers and realize that they will not disappear
>> overnight.
>
>
> People only like solutions when they have a deep problem needing to be
> solved. Giving Haskell to people who are already happy with the status quo
> will not turn any heads. Think about the deep problem that can solved by
> machine-checked specifications and who would be interested. Sorry for the
> vague answer, but it's the best I can give right now.
>
> Hope that helps,
>
> Rahul
>
> [1] http://www.cse.iitk.ac.in/users/karkare/courses/2010/
> cs653/Papers/hudak_haskell_sw_prototype.pdf
>     (Thanks to John Hughes for informing us of this paper at
> FunctionalConf 2016.)
>
> On Thu, Oct 20, 2016 at 6:27 AM, Richard A. O'Keefe <ok at cs.otago.ac.nz>
> wrote:
>
>> TL;DR - Haskell mistaken for pseudo-code, a case study on machine-
>> checked specification for use in standards can't or won't be read
>> by the people who need it (who aren't the people in this mailing list).
>>
>> A couple of years ago, while trying to implement a programming language
>> with >30 years of use and an actual ANSI standard, I encountered a gap
>> in the standard where an aspect of arithmetic was referred to the
>> Language Independent Arithmetic standard, which had in fact nothing
>> whatsoever to say on the topic.  In consequence of this gap, existing
>> implementations of this language implement that feature with different
>> semantics.  Poking around, I found a smaller but similar hole in SQL,
>> and similar issues in other languages.
>>
>> There was no existing specification that any of these could refer to.
>> So I set out to write one.  Having seen other problems in standards
>> caused by definitions that had not been adequately proof-read,
>> I decided that I wanted a specification that had
>>  - been type-checked
>>  - had been tested reasonably thoroughly
>>
>> Since I'm writing in this mailing list, you can guess what I thought
>> was a good way to do this: I wrote the specification in quite direct
>> Haskell, putting effort into clarity at the expense of efficiency,
>> and I used QuickCheck to test the specification.  I still don't know
>> whether to be pleased that QuickCheck found mistakes -- demonstrating
>> my point that specifications need to be checked thoroughly -- or
>> ashamed that I'm still making such mistakes.
>>
>> My problem:  I can't get this published.
>>
>> The backhanded compliment:  the last reviewer excoriated me
>> for having too much pseudocode in my paper.  (Despite the paper
>> stating explicitly that ALL code in the paper was real code that
>> had been executed.)  You got it:  Haskell doesn't look like a "real"
>> programming language, but like something written for human
>> comprehension during design.
>>
>> The dilemma: what I want to do is to tell people working
>> on standards that we NEED to have machine-checked specifications
>> and that we HAVE the technology to write such specifications and
>> test them (oh and by the way here's this specification I wrote to
>> fill that gap).  But people who read Haskell well enough to read
>> my specification don't need to be persuaded of this, and in all
>> honesty, could write the specification for themselves if it
>> occurred to them.  Yet the people who do need to be told that there
>> is a much better way to write standards than say the ECMAScript way
>> don't read Haskell, and won't be interested in learning to do so
>> until they've been persuaded...
>>
>> So where would _you_ send a case study on machine-checked specification?
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
>
>
>
>
> --
> Rahul Muttineni
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20161020/89cabe43/attachment.html>