<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mar. 24 mars 2020 à 15:55, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On Mar 23, 2020, at 9:57 PM, K K Subbu <<a href="mailto:kksubbu.ml@gmail.com" target="_blank">kksubbu.ml@gmail.com</a>> wrote:<br>
> <br>
> On 23/03/20 12:20 PM, Nicolas Cellier wrote:<br>
>> Hi all,<br>
>> since Tim raised the subject, let's return to caesar <a href="https://en.wikipedia.org/wiki/Literate_programming" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Literate_programming</a><br>
>> Otherwise, what Subbu said makes a lot of sense for me.<br>
> <br>
> Thank you for your supportive words.<br>
> <br>
> LP was a great idea for creating books or articles describing code in languages like Pascal or C, but it doesn't fit our needs. Times have changed. Squeak code graph is huge, live and 3D [1]. A static linear rendering will be woefully inadequate.<br>
<br>
+1000.  One of the flaws of Literate Programming is that it presents a post-hoc rationalization of the code, not how it actually came to be.  Another is that it is designed to present a program rather than a library.  Documenting an evolving library, that includes executable examples and tests, is a different thing.<br>
<br></blockquote><div>Agree, I don't think that literate programming perfectly fits very versatile Smalltalk style.</div><div>It's just that we cannot avoid to cite the original conceptor.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Something Alan Kay and I nearly started discussing on Quora is how to write unit tests as both specification and documentation of an API.  This could be literate programming done right.  It doesn’t fit every use case; only certain kinds of API (say sequence manipulation APIs such as includesSubstring:, copyReplace:from:to:with:startingAt:, and arithmetic).  But if the tests are written to be read as a guide one may be able to combine language/api specification with verification and documentation in the same single piece of executable code.<br>
<br></blockquote><div>I would like to see such thing!</div><div>This is the reason why I sometimes tend to write too long tests, like FloatTest>>testCharacterization for the sake of linking the pieces of logic togethers.</div><div>I don't know if it is an antipattern (because the failure reports are no more informative if ran by CI bots), but we need some form of narration.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> [1] Craig Latta's Nexus demo <a href="https://youtu.be/xCwidGFkn4Q" rel="noreferrer" target="_blank">https://youtu.be/xCwidGFkn4Q</a><br>
> <br>
> I expect a modern guide to be like the guided tours in science expos or film studios - live, direct, concrete and interactive. It should be built with the same materials and operated by the same tools (staff) as the rest of the system.<br>
<br>
+1000. Somewhat related, see Tudor Girba’s examples extension of unit tests.<br>
<br>
> <br>
> As Timothy and Tim have pointed out, we already have most of the low level support (doclets, hypertext, help topics) in place. We need a high level perspective and design to get them to work together to create a seamless experience.<br>
<br>
And you, Subbu, have they vision.  I especially liked your characterization of principles, etc, three or do messaged earlier in this thread.  Please push this.<br>
<br></blockquote><div>+1 <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> <br>
> Regards .. Subbu<br>
> <br>
<br></blockquote><div><br></div><div><br></div></div></div>