> On 17 Aug 2017, at 15:24, Esteban Lorenzano <[email protected]> wrote: > > hi Dimitris (good to see you around ;) ), > > thing is… we want to improve our tools. > > And improve tools sometime means to add stuff (I’m not very happy with it > either, I would like to remove more than what I add, but it is like that). > For example, if we want to have good class comments, we need some markup > format, then the best thing we have is pillar and then we need a parser and > then the easiest to use thing we have is petit parser. > > Which means we will need an image that have a core PetitParser and a basic > Pillar… so we can have proper documentation. Of course, maybe the full pillar > is too much (as it is the full petit parser, probably) so we need to think > carefully what we put inside and what we left outside. Same is with > everything: why to put athens, or glamour, or X, Y, Z. (things that few > people use, but are very important for our echosystem in general).
a corollary of this is that, if we think well and we include the correct addition, then it’s exponential (having a real parser inside can easy a lot of developments, and can also lead to better tools). > > Now, along with this “bloating” movements, that adds more elements to the > system and because of that increases essential complexity, we are working on > the other direction: bootstrapping and modularising Pharo so in the near > future (it should be done for P7 or as late to P8) you will be able to create > an image with the elements you want. > > Another thing we need to work on (but that’s in part documentation and in > part modifications to be done) we need to work on overall > availability/comprehensibility of the system. > > So… we need to continue adding things, in order to continue improving. We > also need to remove a lot of things that are duplicated or obsolete. > Pharo will always be “the deliverable we make” (including all things we > officially support as “part of it”)… but we are making possible that > everybody can also do “the Pharo they want”. > > cheers, > Esteban > >> On 17 Aug 2017, at 14:01, Dimitris Chloupis <[email protected] >> <mailto:[email protected]>> wrote: >> >> Is it really necessary ? >> >> I am more a modular guy , I would love to get an image that 0.1% the size of >> the current one and offer me a convenient package manager to install the >> tools I like. >> >> I have used Pillar ALOT probably more than any other Pharo library because I >> was doing Pharo documentation stuff. >> I have even used Pillar to build my website , yeah I know that is not the >> pupose of Pillar but with some modification and the addition of a tool I >> created (Octopus) it help me generate some portion of the website via >> mustache. >> >> Do I want Pillar in ? Nope >> >> Already the System Browser looks like a monster ready to eat you alive, I >> think we need to make the image a lot less threatening especially for >> newcomers. There is such thing as too much info. >> >> Pillar is in the Package Browser you just click and install it if you dont >> mind the wait because its a rather big install. >> >> On Thu, Aug 17, 2017 at 11:27 AM Peter Uhnak <[email protected] >> <mailto:[email protected]>> wrote: >> Even though I've initiated this discussion I kind of stopped reading because >> everyone started discussing completely unrelated things... >> >> The initial point was.... "we are using github/gitlab more and more, lets >> leverage it more" >> >> New, lets separate the concepts at play here... >> >> "Pillar - document model" - the workhorse of pillar and (imho) the most >> important part of it, and also the part I am interested in being included. >> Because then I can generate the document directly without using any syntax... >> >> "Pillar - syntax" - we can have endless arguments whether the syntax is good >> or bad, and imho that should be a separate discussion unrelated to the >> Pillar inclusion >> >> "Markdown for unrelated usecases" - whether you can or cannot write your >> thesis in markdown is really irelevant here >> >> "Markdown - export" - there will always be different variants and extensions >> for Markdown, simply because the sites using markdown offer different >> capabilities. >> >> Therefore the first focus should be on the most impact/effort ratio, which >> is CommonMark (basically the only meaningful Markdown specification), and >> GFM (which is a CommonMark with added tables and strikethrough). >> >> Adding support for more extensive export support, whether code related (e.g. >> GitLab), or code unrelated (writing a thesis) should be a future discussion, >> it is not relevant or too effortful right now. >> >> "Markdown - import" - I would love to be able to write markdown and have it >> imported into the Pillar document model, however that is imho moot point >> right now, as it can always be added later >> >> >> To summarize: >> >> * primary >> * include pillar document model >> * include pillar syntax (as an import format) >> * add CommonMark+GFM export >> * secondary >> * discuss Pillar syntax if needed (in a _new_ thread) >> * discuss Markdown parser / importing CommonMark into Pillar model >> * any other discussion not pertinent here should go elsewhere >> >> Peter >> >> >> On Wed, Aug 16, 2017 at 06:05:29PM +0200, Esteban Lorenzano wrote: >> > Hi, >> > >> > In general (you all know me), I have the policy of “do not go alien just >> > because” which means we do not need to reinvent the wheel all the time and >> > we need to stick with what is already there and known (I have pushed many >> > changes in pharo following this direction, iceberg being just the latest), >> > but we need to keep also the basis of what we are (which means: when we >> > need to stay alien, we need to embrace it too). >> > >> > Said that: while I would LOVE to have a markdown compatible format, the >> > amount of effort put on pillar to make it *what we need* and is a format >> > used not just for doing README.md but to write books, etc., then replacing >> > it would be complicated. >> > >> > but… I think we can do pillar syntax more “markdown alike” (and we can >> > even have a stripped-pillar with would be even more like md), I would >> > salute such change. >> > >> > cheers, >> > Esteban >> > >> > >> > > On 15 Aug 2017, at 19:23, Eliot Miranda <[email protected] >> > > <mailto:[email protected]>> wrote: >> > > >> > > >> > > >> > > On Aug 15, 2017, at 7:25 AM, Ben Coman <[email protected] >> > > <mailto:[email protected]> <mailto:[email protected] >> > > <mailto:[email protected]>>> wrote: >> > > >> > >> >> > >> >> > >> On Tue, Aug 15, 2017 at 12:54 AM, Esteban A. Maringolo >> > >> <[email protected] <mailto:[email protected]> >> > >> <mailto:[email protected] <mailto:[email protected]>>> wrote: >> > >> You hit several birds with one single mail. >> > >> >> > >> 2017-08-14 13:34 GMT-03:00 Tim Mackinnon <[email protected] >> > >> <mailto:[email protected]> <mailto:[email protected] >> > >> <mailto:[email protected]>>>: >> > >> > Jimmie et al. nicely reasoned arguments - and Doru's point about >> > >> > controlling >> > >> > the syntax is an interesting one that I hadn’t thought about. >> > >> > >> > >> > Personally, I find having too many similar syntax’s confusing - >> > >> > contributing >> > >> > to things is hard enough - having to remember that its !! Instead of >> > >> > ## and >> > >> > “” instead of ** is just frustrating for me. >> > >> >> > >> +1 >> > >> >> > >> Not only for docs, most platforms like Slack/Discord share the syntax, >> > >> so now I'm getting "muscle memory" when typing literals using the >> > >> backtick (`) character, quoting with > or pasting snippets using ``` >> > >> >> > >> +1. So I've posted this before... >> > >> >> > >> https://www.joelonsoftware.com/2000/06/03/strategy-letter-iii-let-me-go-back/ >> > >> >> > >> <https://www.joelonsoftware.com/2000/06/03/strategy-letter-iii-let-me-go-back/> >> > >> >> > >> <https://www.joelonsoftware.com/2000/06/03/strategy-letter-iii-let-me-go-back/ >> > >> >> > >> <https://www.joelonsoftware.com/2000/06/03/strategy-letter-iii-let-me-go-back/>> >> > >> describing that "The only strategy in getting people to switch to your >> > >> product is to eliminate barriers" >> > >> >> > >> But more... the best reason for Pillar to support a Markdown-ish >> > >> syntax, is that when we scratch-our-own-itch (nominally for Pillar) to >> > >> build the best damn markup-editor ever (because we can!) - if this >> > >> happened to support Markdown it can draw in Markdown-non-Pharo users >> > >> (because its the best editor ever!). Those users later want to make >> > >> modifications, and now have a *reason* to learn Pharo... ahHaA! now you >> > >> see the cunning plan... >> > >> >> > >> So don't just promote to people "hey come and play with this cool toy >> > >> of ours (Pharo)." >> > >> Instead give them a toy they *already-want* (Markdown editor) and then >> > >> when they want to change the batteries, they *need* to use our special >> > >> screwdriver (Pharo). >> > > >> > > +1! >> > > >> > >> >> > >> cheers -ben >> > >> >> > >> >> > >> > Sure, maybe we were first with Pillar, but for me, lots of >> > >> > programming is in >> > >> > other languages, and I use Smalltalk where I can, and a hybrid of >> > >> > multiple >> > >> > languages and projects is often the reality - so a lowest common >> > >> > denominator >> > >> > of Markdown is just easier. The fact that we are quite close to what >> > >> > our >> > >> > colleagues in other languages use (regardless of what Python has >> > >> > chosen), is >> > >> > quite interesting. >> > >> >> > >> This helps building "bridges" with other communities. >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> The language as a means of exchange is always the lowest common >> > >> denominator. >> > >> As long as it's "efficient enough" then I vote to use what other >> > >> communities use. >> > >> >> > >> > That said, if the community wants to stick to its gun’s thats fine - >> > >> > I will >> > >> > probably still investigate how to use Commonmark for myself, and will >> > >> > still >> > >> > contribute to Pillar docs where I can (and curse history) - but I >> > >> > think we >> > >> > are long better off trying to join emerging standards where we can >> > >> > particularly if they aren’t our core language thing. And it just >> > >> > makes it >> > >> > less frictionless for ourselves and newcomers. >> > >> >> > >> The "Not Invented Here" syndrome is strong among Smalltalkers, it's >> > >> important to be aware of this bias and think more than once whether >> > >> eating our own dogfood adds value to the core of what Pharo brings. >> > >> >> > >> I think we missed some good years fighting with our own SCM and in the >> > >> end git (or any other file based SCM) prevailed, even when it has >> > >> limitations. >> > >> >> > >> Pareto (80-20) for everything non-core business should be a guide. >> > >> >> > >> > Of course, if we were to move, we would need to translate a lot of >> > >> > quality >> > >> > docs to a new format - but I would be up for contributing to that if >> > >> > that >> > >> > was a deciding factor. >> > >> >> > >> There are some Markdown exporters AFAIK, or it could be written. >> > >> >> > >> >> > >> Esteban A. Maringolo >> > >> >
