Thanks Glenn. It's nice to know that this community has at least 3 members that have no problem with adding *extra* support for Markdown (not killing Pillar) :-).
I see that many of your examples come from scientific computing environments (R, Jupyter, Stata). If you're interested in reproducible research with Markdown support in Pharo, you could check Grafoscopio [1]. We have made complete books contained in a single Grafoscopio notebook (see [2]) thanks to the outline capabilities we have in the notebook. It's a feature I have not seen in other scientific computing systems, including Mathematica, Jupyter, R, and I'm aware of being available only on Org Mode and Leo Editor (and of course, Grafoscopio). Having complex (book size) documents organized in single diff-friendly files is very powerful. The integration of Pandoc's Markdown and interactive playgrounds in the Grafoscopio interactive notebooks create a unique computing experience. And because of the self-referential properties of the environment we can put all metadata inside the notebook, as playgrounds of Pharo dictionaries. We don't even use external bash or json config files and all the information for creating a particular output, including external commands are all expressed using just Pharo code. This is how we're creating the (Grafoscopio backed) books & publications. [1] http://mutabit.com/grafoscopio/index.en.html [2] http://mutabit.com/repos.fossil/mapeda/ I think that Smalltalk systems are pretty well suited for reproducible research, because of their self-contained nature and the image concept that allow you to "freeze" a whole computing environment and recover it intact decades later (as we discussed/exemplified in a couple of threads[3][4] recently) and this will be a hot topic in upcoming research on several fronts (science, journalims, activism, etc). This will be improved with Pharo 7 and the possibility to bootstrap the environment from a zero stage. Now imagine if that could be coupled with functional package managers (Chocolatey, Nix, Guix) and a widespread and used light markup language. It could bring a lot of worthy and diverse people to Pharo. It has already done that in a little scale at our local hackerspace [5]. I just want to start with proper support for Markdown inside a more diverse language aware Playground (and helping to build it). [3] https://twitter.com/khinsen/status/938719570235482112 [4] https://twitter.com/khinsen/status/938801977462591490 [5] http://mutabit.com/dataweek/ So yes, the past, present and current efforts for Pillar and Markdown support are worthy and opening a really interesting scenario. Cheers, Offray On 30/12/17 16:41, Glenn Hoetker wrote: > Offray et al, > > Cheers to all who want to add more Markdown capabilities to Pharo. As a > relatively new user who thinks Pharo is one of the coolest systems on Earth, > I would love to see such. I don’t think it is a coincidence that so many new > apps/language/etc. brag about Markdown capabilities (e.g., R lets you write > Markdown, Stata—a stats DSL—has increased its Markdown capabilities, Jupyter > Notebook/Lab has Markdown cells to make writing reproducible analyses easier, > Apple’s Swift has added Markdown-derived documenting features, the iThought > mind-mapping program uses Markdown for formatting, etc.). Despite the > diversity of flavors and certain limitations, Markdown has (Markdowns have??) > clearly become a lingua franca for the larger programming community. Other > humane markup systems like ReStructuredText seem to be more narrow in appeal > (e.g., RST in Python). My personal hunch is that popularity comes from its > ease to write, read as plain text and process using any toolchain aimed at > plain text. > > Many of the things I’ve come to love about Pharo—images, coding and browsing > in the System Browser, the versioning system—are, frankly, barriers to entry > for the novice. Taking Pillar’s strengths and role in making Pharo more > self-contained as given, it is still one more barrier to entry. How great it > would be to provide an easier entry path via Markdown, even if we expect/hope > folks will move to Pillar when they need more and have built up some overall > comfort!!! > > Also, the GFM dialect of Markdown is a key part of the Github ecosystem. So, > Markdown would seem to have at least symbolic—and perhaps practical—synergies > with efforts to integrate with Git. > > Of somewhat less importance, there is an image factor. I personally haven’t > seen tremendous value in having a Markdown parser in Python, Swift, GoLang, > Racket, etc., but it seems like every language except COBOL and, maybe, > BrainF**k now has a Markdown parser. > > Lastly, I sense a concern that Markdown might displace Pillar for many users, > draining energy away from it. On the one hand, that would indicate that it > was better serving the needs of, say, 80% of the users despite being less > capable than Pillar. On the other hand, what to do for the remaining 20% is a > legitimate concern. On the third hand, letting the perfect be the enemy of > the good often doesn’t work out well. > > Which dialect of Markdown gets used seems less important than being able to > handle **a** dialect, whichever it is. If Offray is going to do the work, > seems like it is his choice. (That said, I’m *really* fond of the Pandoc > dialect, even if GFM is most synergistic with Git-ward momentum.) > > Many thanks to all for their past, current and future efforts on both > Markdown and Pillar. > > Glenn > > > Sent from my iPad > >> On Dec 30, 2017, at 1:18 PM, Offray Vladimir Luna Cárdenas >> <[email protected]> wrote: >> >> Sean, >> >> I don't think there is any conflict between having Pillar and Markdown >> support inside Pharo. I tried to explain myself as many times as I can, >> but time and again when Markdown gets mentioned, the next is "we already >> have Pillar" and then a holy war restarts because someone wants another >> markup system supported. All the old arguments for Pillar are mentioned >> and all about (Pandoc's) Markdown ignored and we, the community, rinse >> an repeat as a broken record. >> >> At least this time I know about support existing CommonMark. So maybe in >> 100 to 1000 iterations more of the above community cycle, we could have >> a versatile playground supporting at least two documentation markup >> systems and will be closer to a rich text/document editor system on Pharo. >> >> Cheers, >> >> Offray >> >> >>> On 30/12/17 14:58, Sean P. DeNigris wrote: >>> Stephane Ducasse-3 wrote >>>> Pillar is not about syntax but about the text model and all the visitors. >>> Ah! Good to know. I was also confused on this point. Since we don't yet have >>> a rich text editor, I only ever see static markup and static exports. I >>> should take a deeper look. >>> >>> That said, is there really a conflict with what Offray is saying/doing? IIUC >>> he wants to create a Markdown parser, which presumable could be used to >>> import into the Pillar model (I would assume when the tools become >>> attractive enough to encourage this) and back out to Markdown for >>> interoperability, no? Or am I missing something? >>> >>> >>> >>> ----- >>> Cheers, >>> Sean >>> -- >>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>> >>> >> >> >
