Hi Doru, thanks for the explanation...
I'll end up with three questions: - What makes Bloc different compared to the InterViews and Amulet toolkits? And Unidraw? - Will some of your workflows enables exploration of parallel, non-deterministic programs? - Will we be able to have non-linear execution paths and explorations through examples and documentation? Regards, Thierry 2017-08-27 13:37 GMT+02:00 Tudor Girba <tu...@tudorgirba.com>: > Hi Thierry, > > Indeed, you noticed correctly that we stayed away from the code browser. > > We found several years ago that Morphic was too limiting. During the > Spotter implementation we found ourselves having to construct a > mini-Morphic in order to do what we wanted to do. With text we had several > prototypes for a different kind of editing experience, but we hit a wall. > The interface from the GTInspector is the most rudimentary solution we > could put in place, and it is there mostly as a placeholder to get over the > bridge. > > This is why we joined the Bloc project and we focused all our tool > development effort on it. The goal is to be able to build interfaces that > do not yet exist and that enable workflows that are radically different. We > showed can do that once we have an infrastructure, and we will continue to > do it until we have a full development experience. > > We did not start from the experience of writing code explicitly. That is > because the IDE should encompass all activities including the way we > understand a system, and we think that focusing on reading is to be left > for the previous century. So, we started from the inspector and debugger > and we are making our way towards the writing part. > > Writing code is certainly of deep interest to us. However, the system > browser is the least interesting of the places where we want to write code. > That is because we want to code against live objects, not against dead > text. The main use case the system browser is good for is to organize code > and to find a starting place for getting to a living object. For the rest > of the use cases, there are other solutions that are better. For example, > even with the current Playground, we have people spending more time in > there than in the code browser. That says something given that the > Playground is quite bare at the moment. > > We do not think in terms of tools, but the overall workflows we want to > support. It’s not a race against features, but a reimagining of what an > experience can be like. For example, let’s take documentation: right now, > both producing and consuming documentation happens mostly outside of the > environment. So, the I in the IDE is failing in this respect. We want to > make both of these activities more attractive inside the environment and > the demo you see here is a step in that direction. There is no name for > this tool yet because we tend to not phrase the problem like that. > > Related to other editors, there are indeed WYSWIG tools, but they are > typically not dynamic. There are viewers that are dynamic, but they tend to > not scale well and not be editable. There are tools that scale, but they > are not too visual. And even when there exist some, they are not in an IDE. > So, yes, there are pieces that already exist, but the way we apply them is > novel. > > As for syntax highlighting, it is tied to text and attributes but only to > the extent we wanted it to be. The current implementation is 2k lines of > code. In comparison, just the core of Rubric is 5.5k. But, the rendering is > not related to text whatsoever. Word and adornments are just element that > conform to a layout. So, this means that people can build something else at > a much smaller costs should they want to. > > Cheers, > Doru > > > > On Aug 27, 2017, at 10:43 AM, Thierry Goubier <thierry.goub...@gmail.com> > wrote: > > > > Hi Doru, > > > > 2017-08-27 9:24 GMT+02:00 Tudor Girba <tu...@tudorgirba.com>: > > Hi, > > > > > On Aug 27, 2017, at 12:06 AM, Thierry Goubier < > thierry.goub...@gmail.com> wrote: > > > > > > Hi Tim, > > > > > > 2017-08-26 23:27 GMT+02:00 Tim Mackinnon <tim@testit.works>: > > > I think you pose some interesting design challenges - but it's worthy > of experimentation. > > > > > > I share Denis' enthusiasm to build something better - but it's true > it's not an easy problem space. > > > > > > I'm a big fan of GTInspector, but sometimes I slide across and lose my > context (not always, and not for all types of problems). > > > > > > I think you may be on the key issue, the loss of context when > navigating through the code. In the 90's, that was called the 'lost in > hyperspace' problem linked with hypertexts and hypermedia. > > > > > > I'm not sure it was ever resolved (I stopped following that research > community during my PhD), apart from considering that google solved it for > the web. At least, this would be the choice made by Newspeak: consider that > the code is like the web, and build a system web browser. > > > > > > > > > For unique extractions - inlining is a no brainer (it's just like code > folding in many editors). For non-unique, maybe something in the gutter > might let you easily flip... I don't know, but I'm not convinced our > current way is always optimal. > > > > > > Agreed. I have changed the way I code to reduce the context needed to > understand it. > > > > > > > > > Still, the whole moldable idea is to make it easy to experiment - and > that's the cool bit. That's where we thrive. > > > > > > Smalltalk has allways been open to that sort of experiment. The > moldable bit may make it easier, or at least not more complex than it was > when Smalltalk systems were a lot smaller. Now, is that moldable > implementation really that free, or has it sacrificed certain freedoms to > make moldable things easier? > > > > Please let me intervene briefly :). > > > > Smalltalk was always indeed open. However, we noticed that regardless of > the application domain, tools essentially looked the same for these > systems. All Smalltalkers I asked extended Object at least once, but before > the GTInspector, most of them never extended the inspector. Our language > was extremely dynamic, but our tools less so. That is a conceptual problem > that we address with what we call moldability. > > > > Hum. From 1992 to now, I would make the same statement in the Smalltalk > world, mostly talking a certain conservatism first (look at how much the > system browser has evolved over the years), but also some questions about > efficiency of alternative forms. > > > > For example, the code view of the GTInspector remain for me as one of > the clumsiest, worse view I've ever seen in the Smalltalk world for editing > code. > > > > > > The goal of moldability is to make it inexpensive to customize. To this > end, we approach the IDE as a language and the moldability is captured in > the operators that language provides. Of course, there are limitations to > what can be doable inexpensively. However, it turns out that if you do > manage to bring the cost to a radical low cost, you get much more > extensions and experimentations going on. > > > > I'm a bit missing where the moldability of the IDE went, in that > context. You seem to stear very clear from anything related to the system > browser... > > > > > > All infrastructures make certain things easier and others less so. The > value of all this does depend on what are the operators and how deep in the > infrastructure they are placed. For example, the moldable editor shows > these expandable elements as part of syntax highlighting. Syntax > highlighting existed since a long time, so making it also able to show > other things is quite powerful and requires nothing hardcoded. In fact, I > do not know of any other editor that can do that while still having the > performance we get. > > > > ? Especially that last statement. > > > > Adding non text elements in an editor has allways been a fairly easy > endeavour in ST, as long as I could remember (1993?). > > > > Performance on long texts is orthogonal to Bloc, right? It is present in > all editors that do formatting on long documents since the first WYSIWIG > editors appeared in the 80's. > > > > And, so far, the examples you're showing means that editor isn't as > capable as Doc (in 1989/1990?) was. > > > > I a bit worried about that syntax highlighting approach. It seems to me > very tied to a text + attributes representation instead of an object > representation, and I find that API in Pharo horribly clumsy and > ineffective, for the apparent benefit of slightly reducing object storage > size with a kind of RLE compression. > > > > > > But, even more important than tool features is the behavior of people. > For example, when we first introduced the inspector, all talk was about > details (e.g., how it is clumsy to navigate laterally). 2 years later, at > this year’s PharoDays most talks used the GTInspector in one way or another > to exemplify the presentation. This is a significant impact and this is > what we are after. > > > > Yes. This is clearly where the Pharo platform is showing some innovation > in the ability to shape better object representations. > > > > At the same time, GUI-wise, there is very little innovation in the GUI > language used; GT provides a very limited language, for the sake of > efficiency and ease (*). But maybe it can't be done in another way, if you > want people to really build their extensions. > > > > > > At feenk, we don’t say that we build tools. We see ourselves as > designing experiences. > > > > Which is a worthwhile goal. > > > > Regards, > > > > Thierry > > > > (*) Such layers represent a so huge investment anyway, so it may be > unavoidable. > > > > > > Cheers, > > Doru > > > > > > > > > Regards, > > > > > > Thierry > > > > > > > > > Tim > > > > > > Sent from my iPhone > > > > > > On 26 Aug 2017, at 18:38, Thierry Goubier <thierry.goub...@gmail.com> > wrote: > > > > > >> > > >> > > >> 2017-08-26 15:44 GMT+02:00 Denis Kudriashov <dionisi...@gmail.com>: > > >> No Thierry, Newspeak do not allow it. And it not looks similar to > what I want. > > >> > > >> Hum, you would still get the same overall approach: editor inside > editor (or view inside view). Now, you can say it is not the same, up to > you. > > >> > > >> For me, it has the same effect: the editor isn't in a single place > anymore. You may consider it doesn't matter; IMHO it does matter (and it > makes for me the Newspeak editor slightly less efficient; the same that the > Smalltalk system browser seemed more effective than the Self in-place > method edit, for having used both). > > >> > > >> > > >> Now command+click on selector opens implementors window. In past it > moved browser to single implementor. It was nice and it is how other IDEs > are working. > > >> > > >> You miss the past behaviour? Why not adding it again? > > >> > > >> But as Tim notice it always loses context. And it is quite difficult > to browse long call chain which include many small methods. > > >> > > >> I'm not sure it would solve that one. > > >> > > >> Either it is a long call chain with a fan-out of one, in which case > the developper is creating many useless single line methods because it is > "the right way"(tm), or it has a fan-out greater than one (your typical > polymorphic code) and then each time you open, you have half a dozen > implementors. > > >> > > >> For that, you already have the flow browser. > > >> > > >> So with new editor command+click will be able expand implementor just > in place. I think it will be big improvement for IDE. > > >> > > >> As I said, with Calypso and Nautilus handling badly long methods, > then a method inside a method just makes the top level method longer... I'd > like to see you do that on Metacello or SmaCC code, where important methods > easily go over 50 lines before you expand anything. > > >> > > >> I'd say there that the GTInspector approach would work better -> > expand on the right, with the ability to keep two side by side, and > overlaid with lines clearly showing what has been expanded (for that > "context" thing). > > >> > > >> Regards, > > >> > > >> Thierry > > >> > > >> > > >> 2017-08-26 14:59 GMT+02:00 Thierry Goubier <thierry.goub...@gmail.com > >: > > >> > > >> > > >> 2017-08-26 14:46 GMT+02:00 Denis Kudriashov <dionisi...@gmail.com>: > > >> > > >> 2017-08-26 14:31 GMT+02:00 Tim Mackinnon <tim@testit.works>: > > >> Denis - that's a very cool idea if I've understood you - expand in > the source code of the current method, literally inline? So you could > scroll up and down to view the context as you expand it out? > > >> > > >> Yes, exactly. > > >> > > >> Then that would look a bit like the NewSpeak code browser, if you > would like to try the concept. > > >> > > >> There are disadvantages to that paradigm. One of those is that the > system browser in Pharo is ill-suited to long methods. > > >> > > >> Thierry > > >> > > >> > > >> One of the complaints around refactoring is that you lose context of > surrounding code - intelligent in place expansion would be the best of both > worlds... > > >> > > >> Tim > > >> > > >> Sent from my iPhone > > >> > > >> On 26 Aug 2017, at 11:40, Denis Kudriashov <dionisi...@gmail.com> > wrote: > > >> > > >>> This is really cool. It opens so many possibilities. > > >>> > > >>> I imaging method editor where message sends can be expanded to > implementors just in place. > > >>> > > >>> 2017-08-26 1:03 GMT+02:00 Tudor Girba <tu...@tudorgirba.com>: > > >>> Hi, > > >>> > > >>> We are really pleased to announce another major advancement in the > development of the moldable editor, and most of it was enabled because of > one new feature: expandable elements. We think this will impact > significantly our day to day interactions. > > >>> > > >>> To exemplify what we mean, we will make use of two more alpha > projects that we did not announce yet: GT Documenter (a set of > documentation tools based on Pillar and GT Examples) and GT Mondrian (the > graph visualization engine), both of which are being implemented in Bloc. > > >>> > > >>> Please take a look at the following pictures showing the > documentation Pillar file that ships together with GT Mondrian. What stands > out are the two embedded pictures. These are actually not pictures, but > visualizations rendered live during the viewing of the document out of a > referenced GT Example. > > >>> > > >>> > > >>> > > >>> Now, GT Examples are likely also new for most people. We introduced > them a couple of years ago based on the original idea of Markus Gaelli. > These are a kind of tests that return an object and that can be built out > of other examples. The nice thing is that they are always executable and > testable. So, of course, if you see the resulting object, you can also see > the code that created it, and if you see the code, you can even execute it > live, right in place (notice the preview of the second snippet). > > >>> > > >>> <pillar-mondrian-expanded-preview.png> > > >>> > > >>> Perhaps the most controversial part of GT Examples is that they > offer a mechanism to define static dependencies via pragmas. Please, let’s > leave this debate to another occasion, but please also notice that tools > can use that static information to unfold the code of the referenced method > (notice the nested code editors). > > >>> > > >>> A side note: if you look closer at the list with three items at the > top of the Tutorial section, you will notice numbering next to #. That is > actually syntax highlighting and so is the mechanism that embeds the > expandable elements. It’s really cool. > > >>> > > >>> Taking step back, when we introduced the editor a few weeks ago, we > called it moldable because we said we can make it take different shapes > easily. GT Documenter with everything you see in the above screenshots has > currently ~500 lines of code, and all this while still having an editor > that is highly scalable. > > >>> > > >>> We think that Bloc and Brick will change dramatically face of Pharo > and now we can start to get a glimpse of what is possible. For example, the > use case presented above is more than a technical tool, and we think this > will change both the way we write documentation and the way we consume it. > > >>> > > >>> All these will be presented at ESUG both during presentations and at > the Innovation Awards competition. In the meantime, those that want to play > with it can execute the following in both Pharo 6.1 and Pharo 7.0: > > >>> > > >>> Iceberg enableMetacelloIntegration: true. > > >>> Metacello new > > >>> baseline: 'GToolkit'; > > >>> repository: 'github://feenkcom/gtoolkit/src'; > > >>> load. > > >>> > > >>> And then inspect: > > >>> './pharo-local/iceberg/feenkcom/gtoolkit/doc/mondrian/index.pillar' > asFileReference > > >>> > > >>> Cheers, > > >>> The feenk team > > >>> > > >>> -- > > >>> www.tudorgirba.com > > >>> www.feenk.com > > >>> > > >>> "Innovation comes in the least expected form. > > >>> That is, if it is expected, it already happened." > > >>> > > >>> > > >> > > >> > > >> > > >> > > > > > > > -- > > www.tudorgirba.com > > www.feenk.com > > > > "Problem solving efficiency grows with the abstractness level of problem > understanding." > > -- > www.tudorgirba.com > www.feenk.com > > "Innovation comes in the least expected form. > That is, if it is expected, it already happened." > > >
