<div dir="ltr">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.<br><br>Quoting [1], a study on prototyping software with different languages:<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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).<br>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.</blockquote><br>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.<br><br>Hope that helps,<br><br>Rahul<br><br>[1] <a href="http://www.cse.iitk.ac.in/users/karkare/courses/2010/cs653/Papers/hudak_haskell_sw_prototype.pdf">http://www.cse.iitk.ac.in/users/karkare/courses/2010/cs653/Papers/hudak_haskell_sw_prototype.pdf</a><div>    (Thanks to John Hughes for informing us of this paper at FunctionalConf 2016.)<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 20, 2016 at 6:27 AM, Richard A. O'Keefe <span dir="ltr"><<a href="mailto:ok@cs.otago.ac.nz" target="_blank">ok@cs.otago.ac.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">TL;DR - Haskell mistaken for pseudo-code, a case study on machine-<br>
checked specification for use in standards can't or won't be read<br>
by the people who need it (who aren't the people in this mailing list).<br>
<br>
A couple of years ago, while trying to implement a programming language<br>
with >30 years of use and an actual ANSI standard, I encountered a gap<br>
in the standard where an aspect of arithmetic was referred to the<br>
Language Independent Arithmetic standard, which had in fact nothing<br>
whatsoever to say on the topic.  In consequence of this gap, existing<br>
implementations of this language implement that feature with different<br>
semantics.  Poking around, I found a smaller but similar hole in SQL,<br>
and similar issues in other languages.<br>
<br>
There was no existing specification that any of these could refer to.<br>
So I set out to write one.  Having seen other problems in standards<br>
caused by definitions that had not been adequately proof-read,<br>
I decided that I wanted a specification that had<br>
 - been type-checked<br>
 - had been tested reasonably thoroughly<br>
<br>
Since I'm writing in this mailing list, you can guess what I thought<br>
was a good way to do this: I wrote the specification in quite direct<br>
Haskell, putting effort into clarity at the expense of efficiency,<br>
and I used QuickCheck to test the specification.  I still don't know<br>
whether to be pleased that QuickCheck found mistakes -- demonstrating<br>
my point that specifications need to be checked thoroughly -- or<br>
ashamed that I'm still making such mistakes.<br>
<br>
My problem:  I can't get this published.<br>
<br>
The backhanded compliment:  the last reviewer excoriated me<br>
for having too much pseudocode in my paper.  (Despite the paper<br>
stating explicitly that ALL code in the paper was real code that<br>
had been executed.)  You got it:  Haskell doesn't look like a "real"<br>
programming language, but like something written for human<br>
comprehension during design.<br>
<br>
The dilemma: what I want to do is to tell people working<br>
on standards that we NEED to have machine-checked specifications<br>
and that we HAVE the technology to write such specifications and<br>
test them (oh and by the way here's this specification I wrote to<br>
fill that gap).  But people who read Haskell well enough to read<br>
my specification don't need to be persuaded of this, and in all<br>
honesty, could write the specification for themselves if it<br>
occurred to them.  Yet the people who do need to be told that there<br>
is a much better way to write standards than say the ECMAScript way<br>
don't read Haskell, and won't be interested in learning to do so<br>
until they've been persuaded...<br>
<br>
So where would _you_ send a case study on machine-checked specification?<br>
______________________________<wbr>_________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bi<wbr>n/mailman/listinfo/haskell-caf<wbr>e</a><br>
Only members subscribed via the mailman list are allowed to post.</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Rahul Muttineni</div>
</div>