On Thu, Aug 17, 2017 at 4:25 PM Esteban Lorenzano <[email protected]> wrote:
> hi Dimitris (good to see you around ;) ), > > Not going anywhere , just taking a break from Pharo :) > thing is… we want to improve our tools. > > great > 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. > Yeah.. about that. See the issue is exactly what you just mentioned , improvement. Sometimes improving makes things worse. Markdown class comments is an excellent example of this. You do the logical thing and offer markdown for class comments , you make the image more complex by adding a feature the average user would need but you greatly improve your ability for class comments. But your average user does not even bother adding one line comment on the main class what are the chances that will use markdown ? I am willing to bet big money on "close to zero chance". Hence you end up making things actually worse by adding code that your user wont use and instead increasing the complexity and his motivation to explore and fall in love with your project. > 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). > Well if few people use them, how they are important to your ecosystem ? If you talking about dependencies then that means the ecosystem is deeply flawed and we go back to the modularity question. I fail to see how Athens is important to the Pharo ecosystem , apart from Roassal people I have not seen anyone else using it consistently. If you were talking about the UFFI I would agree 100% but I cannot agree by any means that Athens is so important for Pharo that must be included in the image. By the way I am a graphics guy so biased in favour of Athens. > > 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”. > I can understand having a Parser in image to parse Pharo syntax and other things, big thumbs up for that I think that would justify the inclusion for the average user. Parsing and dealing with text is a big deal afterall. I am ok with offering a minimal image and not being the default one. As long it exists I am happy.
