29 Dec
2018
29 Dec
'18
9:50 p.m.
Hi,
Thanks for the link. For some strange reason, I do not see the linked email in my inbox.
I am happy to hear that you could install GT.
As mentioned above, our focus is to build a new experience. It is likely that a typical
Pharo user will not have much issues adapting to the new interface. A developer that
depended on the old APIs will be somewhat impacted, but we do not expect a too large
effort will be required to adopt the new world.
Nevertheless, if it’s stability and predictability you are looking for, it is best to wait
for now.
I do not think a new piece of code should be called a fork. At this point in time, GT and
everything it comes with, loads cleanly in Pharo 7.
Cheers,
Doru
* The new interfaces and some demo of the graphical
elements look
pretty good
* After just some operations including window resizing I just get the
Red Window of Death [1](https://i.imgur.com/Cbx7uyH.png).
Indeed, that is a known problem:
https://github.com/feenkcom/gtoolkit/issues/64
](http://1](https://i.imgur.com/Cbx7uyH.png)){kind=link}
* I like the little triangles to expand thing in the
document and the
run buttons for embedded code, and the "embeddability" of elements
in the document in a tree like fashion, which of course could lead
to documents that embed pieces of documents, which embed pieces of
documents… But the dual panel view of code in one side with
results in the right panel of old GT didn't tend to create such
"recursion". This dual modal view is the same of
Atom[2](https://is.gd/kegaso) and CodiMD[3](https://is.gd/wudugi)
for interactive documentation and I would like to see examples more
in that line... but I don't know how it suits the philosophy behind
Documenter, which seems more aligned to a modal non dual view of the
document where you enter into edit mode once you click a piece of
the document and into a view mode once you are out of it (instead of
the proposed dual view). Would be nice to see is such dual view can
be used to directly operate on the rendered view and see changes in
the markup (i.e resizing an image in the rendered view changes the
value on the edit view).
Interesting observation. The linked tools as all other notebook technologies I saw rely on
two distinct modes for edit and view that reside in two distinct widgets (editor and
viewer). They do that because they simply cannot have it in one. Because of the design of
Bloc we are not constrained to that. Instead, we build a seamless interface that is both
optimized for viewing, and for editing with live preview that does not rely on an explicit
render button. This approach enables direct manipulation without friction, and we think
this is a significant advancement in this space.
About the remark related "to documents that embed pieces of documents, which embed
pieces of documents”: It is indeed possible to embed documents in documents, but I am not
sure I understand where you see the issue appearing. Could you detail this part?
* I like the different view that a document can
have, markup wise:
Pillar, Markdown, LaTeX, HTML, DeckJS AsciiDoc as is demoed in the
authoring part [4](https://i.imgur.com/Jc1T5Rm.png).
Interestingly, those extensions exist in the old Inspector as well.
](http://4](https://i.imgur.com/Jc1T5Rm.png)){kind=link}
* Its difficult to travel between the panels of a
playground.
Previously you just make click in the lower circle representing the
panel you want to go at it was done
[5](https://i.imgur.com/4CDAM2o.png), but now clicking on the upper
rectangle representing such panel has no effect
[6](https://i.imgur.com/8Obo3Ct.png).
For now, you have to rely on horizontal scrolling using a trackpad or mouse.
Alternatively, Shift+scroll should also work. The upper part is not yet ready.
](http://5](https://i.imgur.com/4CDAM2o.png)){kind=link}
](http://6](https://i.imgur.com/8Obo3Ct.png)){kind=link}
* Auto-completion and shortcuts for selecting text
doesn't work well
on code cells of the new playground. Selecting whole words with Ctrl
arrow doesn't work, neither using down arrows to choose from
suggestions and even you can end with previous suggestions floating
around your playground [7](https://i.imgur.com/4awyIft.png)
[8](https://i.imgur.com/7qXc64b.png).
Indeed. These are known issues that we will tackle soon.
](http://7](https://i.imgur.com/4awyIft.png)){kind=link}
](http://8](https://i.imgur.com/7qXc64b.png)){kind=link}
* The default data science example didn't work
at all
[8](https://i.imgur.com/YhNb8el.png)
Nice catch. Thanks. The path of the file is incorrect when the image is copied.
](http://8](https://i.imgur.com/YhNb8el.png)){kind=link}
> Now, a clarification. The old GT was produced
over a period of 4 years
> by an open-source team. The project had its own identity, and in 2014
> the core of it was first integrated in Pharo. I say the core of it,
> because the visual part and other libraries are not in Pharo today.
>
> The full potential is found in Moose. In any case, during this
> process, GT got to be identified with Pharo and that was a good thing.
> The new GT is a product produced by feenk, a company. Much of the
> original team is still active in the new version, but now we commit to
> our product in a different way. The product is free and open-source,
> but it’s still a product with an identity and a goal. At present time,
> both the team, identity and goal are different than those of Pharo.
>
> Our goal is to offer a fundamentally new alternative to program
> (including comparing to what is possible now in Pharo). We are not
> looking for marginal improvements, and we are not aiming at backward
> compatibility.
I used Moose to build the first Grafoscopio versions,
but there was a
lot of stuff that was related with software analysis that I didn't
really need for reproducible interactive documentation and publishing
nor for data science, activism and storytelling. So once old GT was
integrated into Pharo with Spec I used a more minimal setup to deliver a
more focused experience.
I think that most times this relationship between Pharo and Moose can be
of creative tension, one pushing the boundaries and the other offering a
more stable experience where the innovations of the former are
integrated and debugged. But even after using Moose as a fully
integrated vision of what old GT have to offer in the back and front
end, I didn't see any migration path from previous Moose with the old GT
to the current GT, which is kind of worrisome. I understand the idea of
forks in FLOSS as a way of dealing with politics behind the FLOSS
movement and the relationship between different visions and actors
(individuals, communities, enterprises, foundations, associations and so
on). It has happened before with Squeak, Pharo and Cuis and I'm fine
with that. And I understand that a healthy relationship with the past
means sometimes to break with it and jump into the future.
That's why I think that the role of for profit and non for profit
institutions is to balance a sense of momentum and stability around
FLOSS. I would like to see a more clear road map for GT, knowing ahead
where backward compatibility will be broken and why, which are the
visions and, more importantly, how to participate and where are the
boundaries. These are difficult tasks, but if the participation and
boundaries are explored collectively, you can also know about the first
ones (visions, versions, forks, compatibility). In that sense I think
that Pharo is putting a good example: we have a clear road map document
and participation process in the public repositories, there are public
channels for users and developers and the private companies know about
them, so they can put the boundaries about what is going to be done in
the open, with the community, and what is to be kept closed inside
company's frontiers and channels and the company's own velocity. I don't
know if Feenk is planing something similar for its new vision, product
and identity, and I don't know if the new alternative will have its own
non-profit organizations as a neutral entity for all players using GT,
but would be good to know about that, not because there are not people
willing to jump into the future, but we would like to know to which
future we're jumping on. Without that I think that is a safer bet for
myself to rely on Pharo and see how migration paths could ensure
compatibility with my own past and the one of my local community using
Pharo and GT based tools. I hope that the open source nature of both
products (Pharo and new GT) will ease the cross-pollination of the more
interesting ideas, even without sharing code, visions or UI.
We do not regard our work as an evolution, and we are not concerned with backwards
compatibility. We are not trying to be completely different to what we had before, but
being compatible is simply not a goal. For example, extending oldInspector is usually a
matter of a dozen lines. Extending the new Inspector works in a similar way, but with a
slightly different API that is needed because of the new infrastructure. The migration is
not a pain, and it can happen seamlessly as I described in the mail to Luke.
I understand how from your point of view as a user of Pharo and oldGT you regard backward
compatibility as important. However, we look at things differently. We think that
development can be enhanced both from an efficiency and from a happiness point of view
with a significant degree. When something like this is possible, the opportunities are
different, too. For example, backward compatibility is about limiting costs. However, when
the profit promise can be large, some costs can be worthwhile and are to be considered
investments.
What do we mean by profit? For example, what would it be worth for a company to have the
non-technical people literally pair and understand the internal details of the domain
model? Compared to what exists now, that can be invaluable and we think that following
moldable development this will be a natural by product. Another example: what would it
worth for a developer of a library to build a live documentation with a marginal effort
that simply leverages the testing effort? It can be invaluable, and we think this is
trivially possible.
About the roadmap, here it is: we aim to build a complete development environment that
will enable moldable development.
We understand how this can appear vague. I think it’s not because I and my colleagues talk
about it since many years now. People pay little attention, so now we set ourselves to
deliver a concrete incarnation of what we think the future should look like. We set to
create something that does not exist in other parts, and we simply do not quite know how
this will look like in details. For example, we do know that we want to build a Coder or a
Debugger, we even have advanced ideas and implementations, but we do not know exactly how
it will look like and because of that we also do not quite know how long it will take. We
have a particular way of approaching development that relies on fast feedback and
storytelling, and at the end we always get surprised of where the journey takes us. For
example, the current state of Documenter was simply difficult to imagine even 4 months
ago, and in the process we threw away more code than is now released. So, we will not
detail the concrete steps because we do not work like that.
We do have a clear vision of what we think software development should be, and we will put
forward our guiding principles shortly.
About the governance process: GT is built by feenk and will continue to be so for the
foreseeable future. We put things that we create in the open, we do so for free, and we
welcome people to engage with us.
To build this
alternative we invested in a whole new stack. That is
not a tiny challenge and getting it right requires many iterations and
feedback. We say we are in alpha not because of inconveniences of
installation but because we are still very much developing the product.
We announced the first alpha version in September and since then much
has changed. At present time, we did manage to reach a situation where
downloading the distribution should run on Mac, Linux and Windows.
Even so, the current version is only for people that do want to try
knowing that there will be hurdles.
I think that not only installation inconveniences is related alpha, but
also this jumping from old GT to new one without a clear migration path
(as is expected from alpha software and processes). I'm fine with that
too, but I think that once the new GT reaches beta status the backward
compatibility should be more important and meanwhile the non regard of
that should be stated more promptly for previous and future GT users. I
imagine that, at some point Feenk will provide its users and customers
with clear support and migration paths regarding its open source
products (kind of what happens with Canonical and the Long Term Support
versions of Ubuntu). A word about
the user experience. The current version runs inside the
Pharo UI because we need to bootstrap. But, our goal is to build a
complete IDE on the new stack. If you want to judge the user
experience, it is only meaningful to do it within the GT windows, and
not by comparing it with the rest of the existing Pharo UI.
Does this clarify the situation?
Yes, it does. It seems that a fork is coming, at
least UI wise regarding
Pharo and new GT, but if the community knows about it, I'm fine with
that. I think this thread also clarifies what active users of old GT
will expect from upcoming versions of new (non alpha) GT regarding
compatibility, open processes, visions and so on. Hopefully we will
reach that place together. On Dec 29, 2018, at 5:10 PM, Offray Vladimir Luna
Cárdenas <offray.luna(a)mutabit.com> wrote:
Hi Doru,
This one is still pending:
https://www.list.inf.unibe.ch/pipermail/moose-dev/2018-December/027542.html
Of course we have slow days at end of year and I don't expect immediate
answer, but now that discussion was active is good to point some pending
conversation, even to be taken after holidays.
Cheers,
Offray
On 29/12/18 6:38, Tudor Girba wrote:
> Hi Offray,
>
> I believe I replied to all your emails. If I missed one, please point me to it.
>
> Cheers,
> Doru
>
>
>> On Dec 28, 2018, at 5:12 PM, Offray Vladimir Luna Cárdenas
<offray.luna(a)mutabit.com> wrote:
>>
>>
>> On 28/12/18 8:03, Tudor Girba wrote:
>>>> On Dec 28, 2018, at 1:08 PM, Kjell Godo <squeaklist(a)gmail.com>
wrote:
>>>>
>>>> WOW
>>> :)
>>>
>>> What part of it do you like?
>>>
>>> Cheers,
>>> Doru
>> And which parts you don't?
>>
>> I wrote a long mail regarding good and no so good parts of the new GT
>> experience, including features possible forks, that I hope will be
>> answered also in detail, to keep the big picture.
>>
>> Cheers,
>>
>> Offray
>>
>>
>>
> --
> www.feenk.com
>
> "You can inspect and adapt only what is explicit."
>
>
--
www.feenk.com
"No matter how many recipes we know, we still value a chef."