About balkanisation
Locked
123
123
 
|
Hi,
If anyone *ever* thought we are moving to git because is the new stuff, I need to clarify several things: 1) you don’t know me :) 2) git is not new-cool stuff since a couple of years so is not that we are jumping into anything fancy shiny new (we should be trying to use docker as monticello repositories if that would be the case). Now, let’s talk for real: suppose for a second that you are a software architect (whatever that means) that has in your shoulders the responsibility of drive forward this amazing project called is Pharo. Pharo is a HUGE project with a lot of composants all of them moving. Many times because people introduces changes, others because changes affects others (this is not cool, but happens a lot) and some other simply time passes and world changes around us, which also makes our vision of things change. Now, in this context, as a software architect you do an analysis of risk and you get that Pharo has a lot of them, I will quote just a couple: - As a “moving target”, maintainability is the first big issue: the accidental complexity of the system tends constantly to increase (sometimes, as with some version, at speeds you wouldn’t believe it). Also, incorporating new tools means new things to maintain, constantly. - We do not have enough resources. No idea if we will ever get enough resources, but we do not have enough people to keep maintaining everything and in addition iterate to evolve Pharo. Of course we benefit of been a large community with many people contributing but that is an advantage but also a risk. - People pushes their own agendas. This is perfectly ok, but that means the effort is not measurable nor dirigible :) - tools are OLD. Many of them (including monticello) were built for a world who do not exists any more: software projects are *different* now: bigger, multi-platform, multi-language, N-tier, etc., etc. etc. - … (I can continue all day detecting risks) Now, always as a software architect, you detected an important amount of risks that can make fail your project, and then you have to take decisions to mitigate this risks. One possibility is stop moving. Freezing that part will add a lot of stability to the system… just we will using a relic, and the world will continue changing… others have followed this path. Pharo vision is (and has always been) other… we need, we want to continue moving. So this solution cannot be taken. Other solution is to hire more people. Of course, no money and no money means no more people. Another solution that cannot be taken. So we arrive to a third solution: Reduce the amount of things that needs to be maintained and are “non essential”, so we can concentrate in developing what is actually our thing: we do Pharo. Replacing Monticello with git goes in this direction: - it allows us to stop maintaining sthub (or any other pharo-based repository). Let’s face it: we will NEVER develop a tool as good as github/gitlab/bitbucket/the next thing. Why? Because it is NOT OUT BUSINESS. They have developers there, who’s only work is to do such tool. - but also: it allow developing sotfware projects in ways monticello don’t: multi language, external sources, etc. - but also: it allow CI without us needing to maintain jenkins (another thing that we will able to not maintain anymore… I spent far too much time there and I spent 1% of the time that Christophe spent there, for example). - but also: it reduces the level of “alieness” that newcomers experiments when they arrive to Pharo (let’s face it: most people arrives to Pharo already knowing other languages and most of them are expecting a file-based way of sharing… many of them are expecting git, in fact). In other order of things: - I spent last week replacing a backend made in amber with a backend made in seaside just to remove amber from the equation: so something we need to maintain is pharo-exclusive (this is “architecture 101”: systems complexity increases exponentially for each language you add). - I spent last 3 months aligning the PharoVM with the CogVM, removing what was a “de facto” fork, just to reduce the amount of maintenance effort we need to put there. And to join efforts with Eliot and all others (because joining a larger team and collaborate with them is also a way to incorporate more people into our own VM). - I spent months developing UFFI to remove NativeBoost from the equation with exactly the same purpose: reduce the amount of things we need to maintain. So, as Pharo architect, Pharo fireman, stabilisation faery, whatever you want to call me, it is my responsibility to be sure Pharo will continue moving forward, and this is my answer. But not just me. I work on RMoD team at INRIA. The research team purpose is precisely to support “software evolution”. This means I have the luck of work with some of the best people in the world to ask for this kind of questions. And there is also the Pharo board, who is a group of professionals who knows a bit about pharo and software projects developing. So yes… if you ever thought we are people who jumps to the new-hyped-thing just because is there… think again. Esteban
|
|
In reply to this post by Stephan Eggermont-3
On Sun, Nov 6, 2016 at 6:22 PM Stephan Eggermont <[hidden email]> wrote: Kilon wrote: My first assumption was that you were wrong but respecting your experience as a Smalltalk coder I decided to not fully embrace Git and instead continue to have my project both in Git and in StHub. Few months in this experiment and I confirmed what I suspecting all along that you were wrong. Git requirements is basically non existent, it mainly works with text files and with less support for binary files. Pharo does not need anything but text files to be ready for Git. We had text files since forever with fileouts and became more convenient with filetree. You are also wrong about Seaside kind of projects. Its actually ironic to talk about complex projects when Git itself was made by the creator of Linux and the Linux kernel developers have been using it for the Linux kernel for ages. Actually one of the reasons why Linux created Git was because he was disappointed how slow and cumbersome SVN was with big and complex projects and to this day Git's speed and ability to handle enormous complexity with ease is what makes it first choice for many projects and probably the most popular VCS. Aa such not only SmalltalkHub has been an extremely poor alternativre to Github , its claims like yours that keep the Pharo community using tools that extremely limited , buggy and close to nowhere as Smalltalky enough. I am not talking about here just for Smalltalkhub but also Monticello. That weird Gui thing , that is just weird and sometimes is also weird. If however here we talk personal taste, if people want to recreate tools that exist outside the pharo image because they prefer to stay inside the pharo image , I am not against that but then I never criticised personal taste. Its a free world after all. Tools like Iceberg are more than welcomed as long as I can easily remove them from my image. Personally the only toolset I will be implementing will be a tool to completely bypass monticello and filetree and instead mark classes for export and code will be exported most likely in a fileout format automatically each time I hit accept in the browser. |
|
|
In reply to this post by EstebanLM
Hi Esteban, I cut out the rest, because I agree with all your points, except for...2016-11-07 9:55 GMT+01:00 Esteban Lorenzano <[hidden email]>: [ ... ] And this one I don't understand. A smooth, git / iceberg oriented transition over Monticello/Metacello is perfectly doable... As Dale explained. A nice Iceberg gui reworking / making git usable is perfect. But why make the transition so hard? You get Stef angry on a Sunday morning because he can't find things anymore... even if he is a strong proponent of the strategy he complains about ;) Thierry |
|
|
In reply to this post by kilon.alios
Hi Kilon,
2016-11-07 9:57 GMT+01:00 Dimitris Chloupis <[hidden email]>: Aready done. Look for Jan Vrany tools or Cuis. IMHO, not convincing to me (Jan's format is even more conflict-oriented than Filetree metadata, but it is a design goal). Cuis git repository is a mess to me; very hard to build a coherent 'rebuild a new Cuis here' process on it like I routinely do on Pharo.
Agreed (of course!).
I've seen over the years many, many attempts at replacing the filetree format. I used to contest and debate, now I just let them go and die a few months later. Because none of the alternatives are clearly superior, and it is not worth the effort to reimplement. (I quite enjoy reading filetree-based code on github: it is layed out like my browser, neat and clean. Moreover, all my code involve multiple classes, which means switching between files anyway. Given that reading those !! was never a pleasure, even when I started using Smalltalk in 1991) Regards, Thierry |
Re: about balkanisation
|
|
> On 7 Nov 2016, at 10:13, Thierry Goubier <[hidden email]> wrote: > > I've seen over the years many, many attempts at replacing the filetree format. I used to contest and debate, now I just let them go and die a few months later. Because none of the alternatives are clearly superior, and it is not worth the effort to reimplement. > > (I quite enjoy reading filetree-based code on github: it is layed out like my browser, neat and clean. Moreover, all my code involve multiple classes, which means switching between files anyway. Given that reading those !! was never a pleasure, even when I started using Smalltalk in 1991) Indeed. I agree 100%. |
|
|
> On 7 Nov 2016, at 10:17, Sven Van Caekenberghe <[hidden email]> wrote: > > >> On 7 Nov 2016, at 10:13, Thierry Goubier <[hidden email]> wrote: >> >> I've seen over the years many, many attempts at replacing the filetree format. I used to contest and debate, now I just let them go and die a few months later. Because none of the alternatives are clearly superior, and it is not worth the effort to reimplement. >> >> (I quite enjoy reading filetree-based code on github: it is layed out like my browser, neat and clean. Moreover, all my code involve multiple classes, which means switching between files anyway. Given that reading those !! was never a pleasure, even when I started using Smalltalk in 1991) > > Indeed. I agree 100%. I was even thinking on propose someone (a student project, maybe?) to do an embeddable browser people could put in their README.md, to browse sources “as in Pharo” :) a Seaside app to do that would not be hard, I think… and can be hosted on PharoCloud (or whatever you want). Esteban |
|
|
In reply to this post by Tudor Girba-2
On 11/7/16 2:59 AM, Tudor Girba wrote: > Hi Dale, > > I think I missed your mails. I would be interested in hearing your opinion. Let’s aim for a chat sometime next week. Would this work for you? You're not the only one :) Yes it would ... Monday is a travel day so Tuesday or beyond would work for me ... Dale |
|
|
In reply to this post by EstebanLM
> Am 07.11.2016 um 10:28 schrieb Esteban Lorenzano <[hidden email]>: > > >> On 7 Nov 2016, at 10:17, Sven Van Caekenberghe <[hidden email]> wrote: >> >> >>> On 7 Nov 2016, at 10:13, Thierry Goubier <[hidden email]> wrote: >>> >>> I've seen over the years many, many attempts at replacing the filetree format. I used to contest and debate, now I just let them go and die a few months later. Because none of the alternatives are clearly superior, and it is not worth the effort to reimplement. >>> >>> (I quite enjoy reading filetree-based code on github: it is layed out like my browser, neat and clean. Moreover, all my code involve multiple classes, which means switching between files anyway. Given that reading those !! was never a pleasure, even when I started using Smalltalk in 1991) >> >> Indeed. I agree 100%. > > I was even thinking on propose someone (a student project, maybe?) to do an embeddable browser people could put in their README.md, to browse sources “as in Pharo” :) > a Seaside app to do that would not be hard, I think… and can be hosted on PharoCloud (or whatever you want). > Norbert |
|
|
In reply to this post by Dale Henrichs-3
> Am 07.11.2016 um 10:40 schrieb Dale Henrichs <[hidden email]>: > > > > On 11/7/16 2:59 AM, Tudor Girba wrote: >> Hi Dale, >> >> I think I missed your mails. I would be interested in hearing your opinion. Let’s aim for a chat sometime next week. Would this work for you? > You're not the only one :) Yes it would ... Monday is a travel day so Tuesday or beyond would work for me … > Norbert |
|
|
In reply to this post by Thierry Goubier
" Aready done. Look for Jan Vrany tools or Cuis. IMHO, not convincing to me (Jan's format is even more conflict-oriented than Filetree metadata, but it is a design goal). Cuis git repository is a mess to me; very hard to build a coherent 'rebuild a new Cuis here' process on it like I routinely do on Pharo." Jon Vrany which I found here appears that he has not done any Smalltalk coding for more than a year and I could not find one repo that has such tool. Just to make it clear what I am proposing here is not just a replacement for filetree but I complete bypass of Monticello. I have been a frequent visitor of the pharo mailing lists for more than 5 years not I never head of such a thing. It is also the first time I mention this idea as well. I had in my mind for so long but it has been a low priority because filetree worked without any issues other than browsing the code in code editor and online Github. "I've seen over the years many, many attempts at replacing the filetree format. I used to contest and debate, now I just let them go and die a few months later. Because none of the alternatives are clearly superior, and it is not worth the effort to reimplement." Well if by dying you mean none else but me will use it, most certainly you are correct. But all my projects are foremost personal I never make something for public consumption other than offering a helping hand with Pharo documentation. I am perfectly ok with the fact that people do not use my projects. And foremost its not as if a tool that would bypass monticello and filetree and gitfiletree and iceberg has any chance to be used when for months now the mailing list has been talking about Iceberg. Its clear that I want to live outside the image. Its clear that others want to live inside the image. Its clear that I am a tiny minority , if not the only one. |
|
|
In reply to this post by NorbertHartl
I know :) I’m not saying I will do it… or maintain it… just that it would be cool and fairly easy :P Esteban
|
|
|
In reply to this post by kilon.alios
2016-11-07 10:43 GMT+01:00 Dimitris Chloupis <[hidden email]>:
Cuis basically delegates everything to git and use one file per package.
He has a nice lib interface targetting both mercurial? and git; a kind of ancestor to Pharo libgit effort. Mainly targeted at Smalltalk/X
I mean really dying: like in even the creator isn't using it anymore. You really need good code to hold something alone over the years, something that keeps working across Pharo versions as they evolve with minimum changes. Trust me on that! One strategy is to base yourself on stable core components of Pharo. Some stuff in Pharo changes a lot, some has been very stable since Pharo 3 (or upgraded very nicely while maintaining the same API). You may be better off reimplementing stuff changing too fast / or too buggy in their current incarnation, just to decouple yourself: when you go for a self/alone project, your goals do not align with the main image.
I think you're less radical than you believe :) Thierry |
|
|
In reply to this post by Thierry Goubier
Well… I disagree with this. All my experience says the opposite: this is a convenience usage that in the long way does not match (the thing that we simulate mcz packages do not work… and makes things a lot harder to maintain later). Nico has worked a lot on this, maybe he has something to say.
Stef was angry because he needs to clone, pull, commit, push and make a PR to collaborate… and because that process is not correctly documented/tooled. Sadly, this will not change… it will always be like that. What we can do is easy the task creating the tools… but that will need to be there. Esteban
|
Re: about balkanisation
|
|
In reply to this post by kilon.alios
> On 7 Nov 2016, at 10:43, Dimitris Chloupis <[hidden email]> wrote: > > Its clear that I want to live outside the image. > > Its clear that others want to live inside the image. > > Its clear that I am a tiny minority , if not the only one. I don't understand how you can say that after so many years. The secret, the attractiveness of Pharo/Smalltalk is the _combination_ of the language, the library and the environment (IDE). You can consider these separately and many projects have taken one element out of it to another context. However it is the combination that is magic. Working (developing) command line or file based in Pharo/Smalltalk feels so uncomfortable that it simply hurts. No browsers, no senders/implementors, no workspaces, no inspector, no debugger, no spotter, no interaction, no ... Anyway, this is my opinion and you are of course entitled to yours. Sven |
|
|
In reply to this post by EstebanLM
2016-11-07 11:05 GMT+01:00 Esteban Lorenzano <[hidden email]>:
I'd like to. Simulating mcz? That I don't get it. I've seen many things done in Pharo that have a strong NIH tag attached to them. So I allways take the 'I reimplement everything because I know better' with a grain of salt. Nico has a huge task.
Agreed. It's about time, by the way. Pharo lost some usability on the SLICES/mcz front over the years, and its painfull when teaching Pharo. Thierry |
|
|
In reply to this post by EstebanLM
On 11/7/16 4:52 AM, Esteban Lorenzano wrote: > btw this is pharo-dev discussion, redirecting there. > > Esteban > >> On 7 Nov 2016, at 08:50, Esteban Lorenzano <[hidden email]> wrote: >> >> We are developing Iceberg… and I know is not enough :) >> Which “unifying tools” are you referring ? The main unifying tool is a Metacello Project Browser (or something like the tODE project list). You have a nice tool with the CatalogBrowser (modulo BaselineOf support) ... but you know that already:) but once you load a Project into the image with the CatalogBrowser it sort of disappears ... There needs to be a way to see the _projects_ are loaded in the image ... right now you can see the package loaded into the image, and you can see the dirty packages, but the package is at too low a level From the project browser you should be able to commit a project --- which saves all of the dirty packages in the project --- in one commit for a git project --- all of the dirty packages written in one operation for mcz packages ... This project browser can provide the same set of services for an mcz project (ConfigurationOf) or a filetree project (BaselineOf): - save - load -- this is a bit more complicated to explain (I tried at the Metacello Dr. talk, but more discussion is needed) - diff -- project level diff over a collection of packages - commit log -- For ConfigurationOf, list the commit history of the Configuration. For a BaselineOf list the commit log for the git repository The workflow at the project level is not that different between Mcz and Filetree, so it is straightforward to work with ... The unification comes because you can use one metaphor (project) to work with both Mcz and Filetree ... the underlying implementation will ultimately... The next layer of unified tools is when you look at version history, for a method, you need to provide the ability to view the git commit history for the method (if stored in git) or the image history ... git commit hisotry can be provided at the project/package/class/method ... whereever possible the equivalent mcz/git service should be provided so that the two systems are on an even par ... The Monticello Browser and Iceberg GUI's don't go away, because it is often necessary to do work at the package level, but I think that putting focus on the project is the key ingredient to success for integrating git ... Since git repos are persistent on disk and will be shared ... it is important that there be a way for developers to easily access the git repos for projects that have been cloned locally but not yet loaded in the image itself ... I am really struggling with getting how important this point as this is the also a point that ties a Catalog Browser and Project Browser together I've been using this approach for several years now and once you have the tools and can see at a glance what's "going on in your image" it is fun to work in a mixed environment ... all of this frustration that is bubbling on the list is largely due to not having these missing tools and underlying support --- I think ... >> >> I have followed very close your TOdE development… in a moment I was planning a migration of it for pure-pharo, just… lack of time as always and then later we started iceberg. Yes, I have intended to do a port of tODE to Pharo, but of time is the killer :) >> now, we are in the process of defining a process ;) who works for pharo and is the moment to build the bridges we need, but in general I think that staying "with a foot in two boats” can just work during a very short lapse of time, after that, the stream continues going and if you do not finish your jump into one of the boats you will be very fast in the water. Yes but the two boat environment will last years ... it has taken almost 5 years for filetree to start to be used regularly ... and with the Metacello Project Browser approach the transition will not be nearly as painful, besides I think that the project-centric tools set is required when work with git.... >> >> What I mean is that we can help any transition, but at the end there is no way of having a “nice, coexisting” ecosystem: we will have one OR the other, or something that does not works at all, but we will not have seamlessly one AND the other (which does not means people using monticello will be forced to use git tools or vice-versa, just that you will need to chose one… right now many (many for real) of our problems come from the attempt of keeping our git support behaving as regular monticello… As I say, I think that monticello/filetree can be abstracted away at the Metacello Project Browser level ... a commit of dirty packages writes all the dirty packages for the project in the appropriate repository ... BaselineOf are filetree and ConfigurationOf are mcz ... it doesn't take a whole lot of code to smoothly handle both projects --- as I've said, I have code in tODE that can be looked at for the key trickery and then re-implemented within Pharo without too much trouble ... Then the choice does not have to be made between supporting ConfigurationOf and BaselineOf as both are supported ... eventually a developer may choose to build an image that does not include ConfigurationOf and Monticello support --- but both are needed for at least the next several years >> and that way of doing has a limit. A limit I think we already passed. >> >> Anyway, if you can list what you think we will need for the transition, I will be very glad to see what we can do :) the presentation that I made last Wednesday really covers the most critical things that I think are required ... Metacello Project Browser and load specs are the big ones ... presumably a Project Browser/code browser that allows you to read code at the project level to augment the existing package level code browsers with the commit history integrated at project/package/class/method level ... project level diff tool -- multi-package diffs in one window ... and a git merge tool that does a three-way merge within the image ... Dale |
|
|
> On 7 Nov 2016, at 11:28, Dale Henrichs <[hidden email]> wrote: > > > > On 11/7/16 4:52 AM, Esteban Lorenzano wrote: >> btw this is pharo-dev discussion, redirecting there. >> >> Esteban >> >>> On 7 Nov 2016, at 08:50, Esteban Lorenzano <[hidden email]> wrote: >>> >>> We are developing Iceberg… and I know is not enough :) >>> Which “unifying tools” are you referring ? > The main unifying tool is a Metacello Project Browser (or something like the tODE project list). > > You have a nice tool with the CatalogBrowser (modulo BaselineOf support) ... but you know that already:) but once you load a Project into the image with the CatalogBrowser it sort of disappears ... > > There needs to be a way to see the _projects_ are loaded in the image ... right now you can see the package loaded into the image, and you can see the dirty packages, but the package is at too low a level > > From the project browser you should be able to commit a project --- which saves all of the dirty packages in the project --- in one commit for a git project --- all of the dirty packages written in one operation for mcz packages ... > > This project browser can provide the same set of services for an mcz project (ConfigurationOf) or a filetree project (BaselineOf): > - save > - load -- this is a bit more complicated to explain (I tried at the Metacello Dr. talk, but more discussion is needed) > - diff -- project level diff over a collection of packages > - commit log -- For ConfigurationOf, list the commit history of the Configuration. > For a BaselineOf list the commit log for the git repository > > The workflow at the project level is not that different between Mcz and Filetree, so it is straightforward to work with … this is what is provided by iceberg… it still needs some work, but this is precisely what is supposed to do :) (and btw, this is why I disagree with Thierry some mails below). > > The unification comes because you can use one metaphor (project) to work with both Mcz and Filetree ... the underlying implementation will ultimately... > > The next layer of unified tools is when you look at version history, for a method, you need to provide the ability to view the git commit history for the method (if stored in git) or the image history ... git commit hisotry can be provided at the project/package/class/method ... whereever possible the equivalent mcz/git service should be provided so that the two systems are on an even par … also, this is supposed to be provided by iceberg. > > The Monticello Browser and Iceberg GUI's don't go away, because it is often necessary to do work at the package level, but I think that putting focus on the project is the key ingredient to success for integrating git … Iceberg is not package-oriented. It just show repositories/packages/classes/methods… this is a good way to do it and I do not thing anything is lost like this. You need to take a second look at Iceberg :) > > Since git repos are persistent on disk and will be shared ... it is important that there be a way for developers to easily access the git repos for projects that have been cloned locally but not yet loaded in the image itself ... I am really struggling with getting how important this point as this is the also a point that ties a Catalog Browser and Project Browser together this is something to think… I do not get what catalog browser can do here (but yes, a way to browse local repositories needs to be provided). > > I've been using this approach for several years now and once you have the tools and can see at a glance what's "going on in your image" it is fun to work in a mixed environment ... all of this frustration that is bubbling on the list is largely due to not having these missing tools and underlying support --- I think … I do not think we are so far from your vision. I think you did not get it Iceberg right… please, take a second look :) now… is true that now everything you say is already done… but this is general orientation :) Esteban ps: all of this is *clearly* not pharo-users but pharo-dev discussion, let’s move there. >>> >>> I have followed very close your TOdE development… in a moment I was planning a migration of it for pure-pharo, just… lack of time as always and then later we started iceberg. > Yes, I have intended to do a port of tODE to Pharo, but of time is the killer :) >>> now, we are in the process of defining a process ;) who works for pharo and is the moment to build the bridges we need, but in general I think that staying "with a foot in two boats” can just work during a very short lapse of time, after that, the stream continues going and if you do not finish your jump into one of the boats you will be very fast in the water. > Yes but the two boat environment will last years ... it has taken almost 5 years for filetree to start to be used regularly ... and with the Metacello Project Browser approach the transition will not be nearly as painful, besides I think that the project-centric tools set is required when work with git.... >>> >>> What I mean is that we can help any transition, but at the end there is no way of having a “nice, coexisting” ecosystem: we will have one OR the other, or something that does not works at all, but we will not have seamlessly one AND the other (which does not means people using monticello will be forced to use git tools or vice-versa, just that you will need to chose one… right now many (many for real) of our problems come from the attempt of keeping our git support behaving as regular monticello… > As I say, I think that monticello/filetree can be abstracted away at the Metacello Project Browser level ... a commit of dirty packages writes all the dirty packages for the project in the appropriate repository ... BaselineOf are filetree and ConfigurationOf are mcz ... it doesn't take a whole lot of code to smoothly handle both projects --- as I've said, I have code in tODE that can be looked at for the key trickery and then re-implemented within Pharo without too much trouble ... > > Then the choice does not have to be made between supporting ConfigurationOf and BaselineOf as both are supported ... eventually a developer may choose to build an image that does not include ConfigurationOf and Monticello support --- but both are needed for at least the next several years > > >>> and that way of doing has a limit. A limit I think we already passed. >>> >>> Anyway, if you can list what you think we will need for the transition, I will be very glad to see what we can do :) > the presentation that I made last Wednesday really covers the most critical things that I think are required ... Metacello Project Browser and load specs are the big ones ... presumably a Project Browser/code browser that allows you to read code at the project level to augment the existing package level code browsers with the commit history integrated at project/package/class/method level ... project level diff tool -- multi-package diffs in one window ... and a git merge tool that does a three-way merge within the image ... > > Dale > |
|
|
In reply to this post by Thierry Goubier
yes thats the direction I want to go with this, if possible kill any kind of meta information and turn everything to Smalltalk code. Even fileout contains meta data.
are you talking about this his last commit was 4 years ago. this is going the exact opposite direction once again tries to bring git inside the pharo image. Or are you talking about something else ? "I don't understand how you can say that after so many years. The secret, the attractiveness of Pharo/Smalltalk is the _combination_ of the language, the library and the environment (IDE). You can consider these separately and many projects have taken one element out of it to another context. However it is the combination that is magic. Working (developing) command line or file based in Pharo/Smalltalk feels so uncomfortable that it simply hurts. No browsers, no senders/implementors, no workspaces, no inspector, no debugger, no spotter, no interaction, no ... Anyway, this is my opinion and you are of course entitled to yours." I try to refrain from criticising Pharo, because I don't want to decrease the motivation of people contributing to Pharo which I consider critical to the improvement of Pharo and secondly because my criticisms are largely based on personal taste which I think would make for a very poor discussion since personal taste cannot be debated. The summary of my ideology is that there are only parts of Smalltalk I really like and not the whole thing. I have several ideas about Pharo. Whether some or all of those ideas will be proven bad or too difficult to implement , time will tell. Some of those ideas are 1) a component based environment similar to Delphi (one of the things I loved about Delphi). Basically Objects on steroids. 2) An enhancement of visual coding experience in Pharo. Roassal could help here. 3) The ability to use Emacs as an alternative code editor outside the box. Shampoo has accomplished this goal, but I have not tested it yet. 4) Deep integration with both C++ and Python, this is more than a need since I depend both on Python and C++, this idea is the closest to materialisation and probably my most critical one 5) Modular image = This one I am lucky enough that is already a Pharo goal and an ongoing project 6) A more powerful documentation system , Pillar could help here and the inspector / gtspotter 7) Auto update in the background , not a high priority goal since I will be using the Steam API that handles updates but it would be nice 8) Fragmentation of the image format, this one will be a combination of fuel (or custom format) and bootstrap 9) Removal of any mid ground between Smalltalk code and Git , this is the idea I was talking early on 10) Integration with OS tools , like file browsers, web browsers , system utilities etc 11) Replacement of Morphic with QT, I already can do this at least in part with my python bridge but for now its a low priority 12) Management of user analytics, that will be specific to my games and probably will utilise Steam's and Unreal's analytics for gathering information about the user , obviously with the permission of the user, most likely this will require minimum Pharo code 13) Unification of Browser, Workspace , GTInspector, GTDebugger and GtSpotter under one tool 14) More strict evaluation of potential errors and user mistakes and many more. All those ideas are mostly long term so it may be years if not a decade before they materialise and probably will change along the process to fit practical needs. You could say that Ephestos most likely will turn into an alternative Pharo Distribution like Cuis is for Squeak but with very different goals. Again my goal is not to produce something for public consumption but merely an image that follows more closely my personal taste. |
|
|
In reply to this post by NorbertHartl
On 11/7/16 6:42 AM, Norbert Hartl wrote: >> Am 07.11.2016 um 10:40 schrieb Dale Henrichs <[hidden email]>: >> >> >> >> On 11/7/16 2:59 AM, Tudor Girba wrote: >>> Hi Dale, >>> >>> I think I missed your mails. I would be interested in hearing your opinion. Let’s aim for a chat sometime next week. Would this work for you? >> You're not the only one :) Yes it would ... Monday is a travel day so Tuesday or beyond would work for me … >> > Would it make sense to make that a group conversation? > some of the "simple concepts" ... My talk last Wednesday was my first attempt and I don't think I did a good job of communicating about some of the more complicated tasks that come up like: load specs, clone/lock/rehome, sharing local clones across multiple images, private image clones, etc. ... My inclination is to have a focused conversation with Doru to help me express the key concepts ... then a more public discussion with another straw man where we put the ideas out again ... Dale |
|
|
In reply to this post by Thierry Goubier
On 11/7/16 7:15 AM, Thierry Goubier
wrote:
Thierry, If I'm not mistaken, Esteban is referring to the fact that in FileTree we are still using Monticello to do the load of the packages and even when we are running metadataless, we end creating fake meta data to simulate an mcz ... you and I have had conversations about ways to eliminate this "requirement" because it is meaningless in a git context ... With the work that Richard Sargent did on the CypressReferenceImplementation, I would prefer to say that Cypress can provide an Alternative to Monticello rather than replace it ... the CypressReferenceImplementation includes a package loader so it isn't necessary to convert Filetree format on disk to Mcz format in the image --- without all of the ancestry, "latest version stuff" and package-cache the loading process becomes much, much simpler... I think that both Monticello and Cypress can live together in the image ... I have created a version of Metacello that uses Monticello OR Cypress and I expect to eventually (in the next several months --- it doesn't take that long, but I've got other things on my plate) to have a version of Metacello that uses Monticello AND/OR Cypress again I think that smooth transitions (that may take a long time) are better supported in this fashion than to draw a line in the sand and force the usage of one OR the other ... Dale |
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |