On 28/12/15 17:05, stepharo wrote:
Yes, that is true. That is a cost of a smaller community. But the
problem here is that your solution creates a self fulfilling
situation. If everybody who comes to Pharo is encouraged to use tools
outside of Pharo rather than using, improving and extending the tools
in Pharo. Then the community is working against itself. And the tools
never reach what the person was wanting to use.
+1
-1 with explanation ;-) :
I don't think this will be the necessary case more if Pharo is a long
term game. Pharo needs to work better with the external world. It's
already trying to make that with Git and the abstracting the DVCS layer,
its putting tools like fossil in the radar. I don't think that making
the same for flat file web site generators (static like Nikola or
dynamic like grav) and light markup and data serialization languages is
different that trying to work better with flat file source code
management systems or that is having the community working against
itself. I have proposed a long/mid term game by using Asbtract Syntax
Trees to work better with Pandoc. Trying to not reinvet git/fossil
inside Pharo is a good thing the community and doesn't preclude the use
and improvement of Monticello. Trying to not reinvet grav/nikola/pandoc
inside Pharo its also a good think and doesn't preclude esctatic/pillar
exploration and improvement, but in a long term game playing well with
others with different combinations could be wiser.
Pharo will improve more at a minimum if the people who love Pharo use
Pharo to scratch their itches and use Pharo to create the tools to
scratch their itches. If we continually look outside, we might as
well go outside. Pharo is more like an operating system/environment
than a simple language. More like Linux/Unix and C/Python, than C or
Python alone. We prefer our tools to be written native to our
environment rather than external to it. It is different that Python,
Ruby, Lua, PHP or whatever.
There are so many advantages to using tools in Pharo when using
Pharo. Since Pharo is a full environment on top of any OS, it is
exceptionally portable. Put it in a folder on a flash drive with
appropriate VMs and off you go.
It is also so easy to simply snapshot where you are to save your
state in development or exploration of a problem. So many things that
are easy in Pharo that are difficult, hard or near impossible to do
elsewhere.
I understand that, and the dynamic nature of the environment makes that
"reinvention" inside it to make a lot of sense because we have the
interactivity we're used to. But that doesn't preclude playing well with
others (including other languages, frameworks and tools) without meaning
that we will go outside for everything and leave Pharo as a ghost town
(it doesn't happen with DVCS like git).
If Pharo users were to drop Pillar and begin to use Pandoc, then we
be using tools that we have no control over and tools that we are
likely not to contribute to development of. If we then had an need
which is not met by the tools, then what do we do? Do we now adopt
yet another language, environment, editor, ... in order to meet that
need? That is fine for people whose preferred environment and toolset
is so defined. But that is not the preferred way in Pharo (or
Smalltalk).
Same applies for git and nobody is talking about a self fulfilling
prophesy here.
Pharo is a long game tool. We are happy to grow it slow, steady and
stable. We are happy to have more and more help to do so. We want to
grow Pharo and its tools. Not Pandoc, Python and their tools. They
are able to take care of themselves. I want to be using the evolving
Pharo environment and tools not just now, but in 10 years, in 20
years. I see no other tools (outside of the Smalltalk world) that
have this kind of vision. This is best served by contributing to the
environment and the tools in Pharo. Rather than doing what might be
expedient in the here and now. It affects my here and nows in the
future in a more profitable and productive way.
+1
+-1. Fortunately this is a diverse community where making pharo better
doesn't imply it will not work fine with other languages, frameworks,
cultures: See ephestos and bridges with python/blender, FileTree and
bridges with git or grafoscopio and bridges with pandoc.
Now there are times when venturing outside of Pharo is required. And
when that time occurs, we need to be exceptionally well able to do
so. And I see great hope on that front.
But when we do not need to venture outside of Pharo. Those of us who
believe in the vision of Pharo are much more highly advantaged by
contributing to the tools in this community. Than to looks outside
the community for tools which my momentarily meet a need.
That moment is different for each of us. I need footnotes and
bibliographic references and integration with zotero now. Pandoc gives
me that and Pillar doesn't. Some people need now things that git has and
monticello doesn't. That doesn't mean that we're not working in the
pharo improvement and vision, but by leveraging into tools like
git/pandoc the stuff we can focus only in the long term game, we can
made more valuable contributions now where we consider our interest and
skills more valuable, that in reimplementing features of git/pandoc
inside Pharo, which doesn't preclude of others of making improvements in
the fronts of native DVCS or documentation.
I think adding footnotes to Pillar is a great idea. I am not ready to
do so. I am not a qualified Pillar user yet. But when I am, I would
not hesitate to add it to Pillar and improve the tool of the
environment I prefer to use.
When I become a more proficient user of smalltalk and pharo I would like
to use Abstract Syntax Trees for scripting and manipulation of pandoc
inside pharo. Meanwhile I will try to focus on interactive documentation
and data visualization inside pharo, but using external tools and
markups for import/export.
Just my 2 cents. It is worth what you paid for it. :)
Shalom.
Jimmie
My 2 cents more.
Cheers,
Offray
