I remember my 10 year self struggling learning to code basic back in 1988 on an Amstrad CPC 6128 with Locomotive Basic that required entering line numbers before the code statement. IDEs , code editors and what else were unheard of for me at least and even if they did exist would be nowhere near the budget of a 10 year old.
Nowdays we have a ton of options, easy access to it, its free , its open source, insanely powerful and even documented. You can even find Youtube tutorials if too lazy to read text and also a ton of examples and snippets to get you started. I agree 1000% with your argument that "batteries included" version is super important, its one of the major reason why Python exploded in popularity. But yeah I turn to Hulk every time I hear these dreaded 3 words "too many options". I am willing to endure this hell of too many options and even pray it gets much much worse. But then it may be just me :) On Thu, Aug 17, 2017 at 5:50 PM Dimitris Chloupis <[email protected]> wrote: > 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. >
