Behold Pharo: The Modern Smalltalk
Locked
1234567
... 9
1234567
... 9
Re: Behold Pharo: The Modern Smalltalk
 
|
I dunno, maybe I’m weird, but I find the System Browser a fantastic way to explore the class library. If you find a class or method that isn’t well documented, write a comment and send a change request. Stef told me this ages ago. I might add, if you find a bug you should write a test that exercises the bug and submit it on fogbugz (the bug tracking system). I will reference of response of mine to a similar opinion made by Richard: https://medium.com/@vitormcruz/i-disagree-it-is-much-harder-to-find-anything-in-the-environment-c6bdd44f6eea My 2 cents. On Tue, Oct 10, 2017 at 11:59 PM, john pfersich <[hidden email]> wrote:
|
Re: Behold Pharo: The Modern Smalltalk
|
for me it is a yes and no situation, yes its very coold to have your entire system in your fingertips but Pharo has serious issues with code organisation and I find the lack of namespaces quite inconvenient. You have to be careful how to name your classes which does not sound to me very OOP friendly. Also the IDE does not handle spaggetification very well, sure you can find implementors , senders etc but if the execution chain is complex , welcome to spaggeti hell. But that is a problem with most other IDEs if not all as well. Problem is in this case that we have the very good rule of using sort methods which multiplies this problem and makes navigation even harder. Code becomes much easier to read per method and messages but much harder to understand in a bird eye view. Some of that pain has been aleviated with the introduction of GTSpotter which I have praised quite a lot and I will continue to do so. But yeah there are more needed to be done in the department to make Pharo code navigation a more comfortable task. On Wed, Oct 11, 2017 at 2:57 PM Vitor Medina Cruz <[hidden email]> wrote:
|
|
|
In reply to this post by horrido
horrido <[hidden email]> wrote:
> Interestingly, I'm getting a fair amount of pushback on this. Personally, I > think it would be very helpful to have a live (updatable, so as to keep it > current) reference page for the class library, something that developers can > easily look up what they need. After all, most of the power of Pharo comes > from the class library and we need to make it as accessible as possible to > less experienced Pharoers (i.e., beginners). > > Exploring the class library through the System Browser is very inefficient. > This is further exacerbated by the fact that many classes and methods are > simply not well-documented (containing a cursory remark which is just barely > useful). > > I realize that creating a live reference page is not easy to do. In fact, > it's a lot of work. But the absence of such a page is a real obstacle to > Pharo acceptance. > I have a simple example compoared with python. I want to programatically find the version number of current instance. In Python I go to the document page e.g. <https://docs.python.org/3/> and search for version. I get a pageful of hits which I can read and find the snswer (ie sys.version) For Pharo what search do I do? You don't need to implement a seach engine Google, Bing etc can do this and with a lot more resopuirces than Pharo can do, but you need the information in a restricted place e.g. one site. and it does not need to be dynamic The first thing I do for a new technology is RTFM. > > > horrido wrote > > Thanks. I gave your answer verbatim. I also added the following paragraph: > > > > The problem I find with today's developers is that they are rather > > closed-minded. They are rigid and inflexible, and not willing to adapt to > > new and different ways of doing things. In my generation (circa > > 1980–1990), > > people didn't have a problem with trying different technologies. That's > > why > > I had no issue with learning Smalltalk 10 years ago, after I had retired > > from a 20-year-long career in C systems programming and FORTRAN scientific > > programming. > > > > > > > > Sven Van Caekenberghe-2 wrote > >>> On 6 Oct 2017, at 14:54, horrido < > > > >> horrido.hobbies@ > > > >> > wrote: > >>> > >>> I received this comment from someone who complained: > >>> > >>> *What about the lack of documentation? From time to time I've checked > >>> some > >>> SmallTalk implementations like Squeak, GNU-Smalltalk and now Pharo. Of > >>> these, only GNU-SmallTalk appears to have a free, official programming > >>> guide > >>> and core library reference that any serious programmer expects from a > >>> language. > >>> > >>> https://www.gnu.org/software/smalltalk/manual-base/html_node/* > >>> > >>> I pointed to Pharo's documentation but then he came back with: > >>> > >>> *Then show me a link of the free, maintained reference documentation for > >>> the > >>> classes that form "the core library", like this one for Python > >>> (https://docs.python.org/3/library/index.html)* > >>> > >>> It's true, most Smalltalks do not have a core library reference, not > >>> even > >>> VisualWorks! So what is the proper response to this complaint? > >> > >> The first answer is that Pharo/Smalltalk is unique in that a running > >> system/IDE contains _all_ source code, _all_ documentation (class, > >> method, > >> help, tutorial), _all_ unit tests and _all_ runnable examples in a very > >> easy, accessible way. It takes some getting used to, but this is actually > >> better and much more powerful than any alternative. > >> > >> The second answer is that there are lots of books and articles that take > >> the classic/structured book/paper approach. There is > >> http://books.pharo.org, http://themoosebook.org, > >> http://book.seaside.st/book, http://medium.com/concerning-pharo and many > >> more. > >> > Mark |
Re: Behold Pharo: The Modern Smalltalk
|
|
In reply to this post by kilon.alios
The more I use Pharo, the less I use web documentation. For me seems pretty suboptimal compared to live environment with code browser and GT-Spotter. Regarding the comment on Medium, it also took me little to find #raisedTo:, so the millage can vary. What I was missing was proper books for particular domains, but Pharo books are covering that. I don't know if a Q&A site could improve search-ability for newbies (certainly you can find little stuff in Stack Overflow). My bet is about trying to create more "end user" tools (Grafoscopio is kind of this), besides tools for developers. There is a broad community of people who can be active contributors and members of the community, welcome Pharo and live coding a lot and don't complain that much about stuff that is not already pretty similar to what they already know (being that only English MOOC or online static html docs). Cheers, Offray On 11/10/17 07:34, Dimitris Chloupis
wrote:
|
Re: Behold Pharo: The Modern Smalltalk
|
|
Docs are available in static online html format , at least the book I was working on
Pharo By Example You can find those links here https://github.com/SquareBracketAssociates/UpdatedPharoByExample Our documentation system , Pillar , outputs pdf , html and markdown files. If the book in question is built like PBE with CI of Inria where most Pharo related official projects are built then it should have at least pdf and html with online access so you can easily link to. Don’t quote me on this but I think the html output of pillar generate links even for paragraphs you can do an even more process linking to the documentation. On Wed, 11 Oct 2017 at 17:40, Offray Vladimir Luna Cárdenas <[hidden email]> wrote:
|
Re: Behold Pharo: The Modern Smalltalk
|
|
Ah and my static website was built with Pillar and Bootstrap, using bootstrap templates was easy because Pillar supports mustache that makes html manipulation much easier
http://www.kilon-alios.com Pillar of course is not made for generating websites but it’s an awesome Pharo library that allows for great degree of freedom so I thought , why not ? On Wed, 11 Oct 2017 at 17:48, Dimitris Chloupis <[hidden email]> wrote: Docs are available in static online html format , at least the book I was working on |
Re: Behold Pharo: The Modern Smalltalk
|
|
Yes. I know them. I mean API docs as static files. I don't really sold on them compared with a live system and I don't think static API docs are critical for Pharo success. Cheers, Offray On 11/10/17 09:52, Dimitris Chloupis
wrote:
Ah and my static website was built with Pillar and Bootstrap, using bootstrap templates was easy because Pillar supports mustache that makes html manipulation much easier |
Re: Behold Pharo: The Modern Smalltalk
|
|
What about a seaside-based system browser oriented towards code documentation? That would fit both paradigms: html-like reference + live browsing.
You could even make it buzzword compliant: have a REST interface to documentation and code. Note how the panes in a system browser could make for a nice URI: just look for pharo://Kernel/Number/mathematical%20functions/raisedTo: And we could even include version numbers, etc.... pharo://6.1/Kernel/Number/mathematical%20functions/raisedTo: Not very different from the github url for the pharo project relevant file... Thierry 2017-10-11 17:01 GMT+02:00 Offray Vladimir Luna Cárdenas <[hidden email]>:
|
Re: Behold Pharo: The Modern Smalltalk
|
|
> On 11 Oct 2017, at 17:18, Thierry Goubier <[hidden email]> wrote: > > What about a seaside-based system browser oriented towards code documentation? That would fit both paradigms: html-like reference + live browsing. > > You could even make it buzzword compliant: have a REST interface to documentation and code. > > Note how the panes in a system browser could make for a nice URI: just look for > > pharo://Kernel/Number/mathematical%20functions/raisedTo: > > And we could even include version numbers, etc.... > > pharo://6.1/Kernel/Number/mathematical%20functions/raisedTo: > > Not very different from the github url for the pharo project relevant file... > > https://github.com/pharo-project/pharo/blob/development/src/Kernel.package/Number.class/instance/raisedTo..st Indeed. Too bad there are plans to put everything in one file (booo) ;-) > Thierry > > 2017-10-11 17:01 GMT+02:00 Offray Vladimir Luna Cárdenas <[hidden email]>: > Yes. I know them. I mean API docs as static files. I don't really sold on them compared with a live system and I don't think static API docs are critical for Pharo success. > > Cheers, > > Offray > > On 11/10/17 09:52, Dimitris Chloupis wrote: >> Ah and my static website was built with Pillar and Bootstrap, using bootstrap templates was easy because Pillar supports mustache that makes html manipulation much easier >> >> http://www.kilon-alios.com >> >> Pillar of course is not made for generating websites but it’s an awesome Pharo library that allows for great degree of freedom so I thought , why not ? >> On Wed, 11 Oct 2017 at 17:48, Dimitris Chloupis <[hidden email]> wrote: >> Docs are available in static online html format , at least the book I was working on >> >> Pharo By Example >> >> You can find those links here >> >> https://github.com/SquareBracketAssociates/UpdatedPharoByExample >> >> Our documentation system , Pillar , outputs pdf , html and markdown files. >> >> If the book in question is built like PBE with CI of Inria where most Pharo related official projects are built then it should have at least pdf and html with online access so you can easily link to. >> >> Don’t quote me on this but I think the html output of pillar generate links even for paragraphs you can do an even more process linking to the documentation. >> On Wed, 11 Oct 2017 at 17:40, Offray Vladimir Luna Cárdenas <[hidden email]> wrote: >> The more I use Pharo, the less I use web documentation. For me seems pretty suboptimal compared to live environment with code browser and GT-Spotter. Regarding the comment on Medium, it also took me little to find #raisedTo:, so the millage can vary. What I was missing was proper books for particular domains, but Pharo books are covering that. I don't know if a Q&A site could improve search-ability for newbies (certainly you can find little stuff in Stack Overflow). >> >> My bet is about trying to create more "end user" tools (Grafoscopio is kind of this), besides tools for developers. There is a broad community of people who can be active contributors and members of the community, welcome Pharo and live coding a lot and don't complain that much about stuff that is not already pretty similar to what they already know (being that only English MOOC or online static html docs). >> >> Cheers, >> >> Offray >> >> On 11/10/17 07:34, Dimitris Chloupis wrote: >>> for me it is a yes and no situation, yes its very coold to have your entire system in your fingertips but Pharo has serious issues with code organisation and I find the lack of namespaces quite inconvenient. You have to be careful how to name your classes which does not sound to me very OOP friendly. >>> >>> Also the IDE does not handle spaggetification very well, sure you can find implementors , senders etc but if the execution chain is complex , welcome to spaggeti hell. But that is a problem with most other IDEs if not all as well. Problem is in this case that we have the very good rule of using sort methods which multiplies this problem and makes navigation even harder. Code becomes much easier to read per method and messages but much harder to understand in a bird eye view. >>> >>> Some of that pain has been aleviated with the introduction of GTSpotter which I have praised quite a lot and I will continue to do so. But yeah there are more needed to be done in the department to make Pharo code navigation a more comfortable task. >>> >>> On Wed, Oct 11, 2017 at 2:57 PM Vitor Medina Cruz <[hidden email]> wrote: >>> I dunno, maybe I’m weird, but I find the System Browser a fantastic way to explore the class library. If you find a class or method that isn’t well documented, write a comment and send a change request. Stef told me this ages ago. I might add, if you find a bug you should write a test that exercises the bug and submit it on fogbugz (the bug tracking system). >>> >>> I will reference of response of mine to a similar opinion made by Richard: https://medium.com/@vitormcruz/i-disagree-it-is-much-harder-to-find-anything-in-the-environment-c6bdd44f6eea >>> >>> My 2 cents. >>> >>> >>> >>> >>> On Tue, Oct 10, 2017 at 11:59 PM, john pfersich <[hidden email]> wrote: >>> >>> > On Oct 10, 2017, at 09:58, horrido <[hidden email]> wrote: >>> > >>> > Interestingly, I'm getting a fair amount of pushback on this. Personally, I >>> > think it would be very helpful to have a live (updatable, so as to keep it >>> > current) reference page for the class library, something that developers can >>> > easily look up what they need. After all, most of the power of Pharo comes >>> > from the class library and we need to make it as accessible as possible to >>> > less experienced Pharoers (i.e., beginners). >>> > >>> > Exploring the class library through the System Browser is very inefficient. >>> > This is further exacerbated by the fact that many classes and methods are >>> > simply not well-documented (containing a cursory remark which is just barely >>> > useful). >>> > >>> I dunno, maybe I’m weird, but I find the System Browser a fantastic way to explore the class library. If you find a class or method that isn’t well documented, write a comment and send a change request. Stef told me this ages ago. I might add, if you find a bug you should write a test that exercises the bug and submit it on fogbugz (the bug tracking system). >>> >>> > I realize that creating a live reference page is not easy to do. In fact, >>> > it's a lot of work. But the absence of such a page is a real obstacle to >>> > Pharo acceptance. >>> > >>> > >>> > >>> > horrido wrote >>> >> Thanks. I gave your answer verbatim. I also added the following paragraph: >>> >> >>> >> The problem I find with today’s developers is that they are rather >>> >> closed-minded. They are rigid and inflexible, and not willing to adapt to >>> >> new and different ways of doing things. In my generation (circa >>> >> 1980–1990), >>> >> people didn’t have a problem with trying different technologies. That’s >>> >> why >>> >> I had no issue with learning Smalltalk 10 years ago, after I had retired >>> >> from a 20-year-long career in C systems programming and FORTRAN scientific >>> >> programming. >>> >> >>> >> >>> >> >>> >> Sven Van Caekenberghe-2 wrote >>> >>>> On 6 Oct 2017, at 14:54, horrido < >>> >> >>> >>> horrido.hobbies@ >>> >> >>> >>> > wrote: >>> >>>> >>> >>>> I received this comment from someone who complained: >>> >>>> >>> >>>> *What about the lack of documentation? From time to time I’ve checked >>> >>>> some >>> >>>> SmallTalk implementations like Squeak, GNU-Smalltalk and now Pharo. Of >>> >>>> these, only GNU-SmallTalk appears to have a free, official programming >>> >>>> guide >>> >>>> and core library reference that any serious programmer expects from a >>> >>>> language. >>> >>>> >>> >>>> https://www.gnu.org/software/smalltalk/manual-base/html_node/* >>> >>>> >>> >>>> I pointed to Pharo's documentation but then he came back with: >>> >>>> >>> >>>> *Then show me a link of the free, maintained reference documentation for >>> >>>> the >>> >>>> classes that form “the core library”, like this one for Python >>> >>>> (https://docs.python.org/3/library/index.html)* >>> >>>> >>> >>>> It's true, most Smalltalks do not have a core library reference, not >>> >>>> even >>> >>>> VisualWorks! So what is the proper response to this complaint? >>> >>> >>> >>> The first answer is that Pharo/Smalltalk is unique in that a running >>> >>> system/IDE contains _all_ source code, _all_ documentation (class, >>> >>> method, >>> >>> help, tutorial), _all_ unit tests and _all_ runnable examples in a very >>> >>> easy, accessible way. It takes some getting used to, but this is actually >>> >>> better and much more powerful than any alternative. >>> >>> >>> >>> The second answer is that there are lots of books and articles that take >>> >>> the classic/structured book/paper approach. There is >>> >>> http://books.pharo.org, http://themoosebook.org, >>> >>> http://book.seaside.st/book, http://medium.com/concerning-pharo and many >>> >>> more. >>> >>> >>> >>>> Thanks. >>> >>>> >>> >>>> >>> >>>> >>> >>>> -- >>> >>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>> >>>> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> -- >>> >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>> > >>> > >>> > >>> > >>> > >>> > -- >>> > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>> > >>> >>> >> > > |
Re: Behold Pharo: The Modern Smalltalk
|
|
In reply to this post by Thierry Goubier
There is http://files.pharo.org/doc/, too. Marcus |
Re: Behold Pharo: The Modern Smalltalk
|
|
Seaside for html live docs browsing seems a good idea. How do you create something like [1]?: Cheers, Offray On 11/10/17 10:31, Marcus Denker wrote:
|
Re: Behold Pharo: The Modern Smalltalk
|
|
In reply to this post by kilon.alios
On Sat, Oct 07, 2017 at 01:41:17AM +0000, Dimitris Chloupis wrote:
> execution. Hence live coding, the Python VM replaces objects lively. Python > can also compile any size of code including individual methods. > That happens with one line of code importlib.reload(mymodule) AFAIK in Python when you modify and reload source, existing instances are not "reshaped" to the modified code. Not live enough. Of course with Python objects it is easy to add per-instance inst-vars, but still this needs to be scripted and doesn't come free with the programming environment. Pierce |
Re: Behold Pharo: The Modern Smalltalk
|
|
Yes sorry for not making this clear. I was wrong in this case. A module reload will only replace class objects not instance objects. So if you create a new instance after the reload it will have the updated version but your old instance would not. I try to test something before I make a claim but in this case I failed because I forgot the obvious. The tiny fact I was reinitialising my objects in the python project I am currently using live coding, so of course my instances were updating instantenously because I was in a loop that was recreating them every few milliseconds. When webwarrior mentioned this it draw my supisions and I tested it outside my code in the interpreter and it became obvious I was wrong. This why my reply I dont claim he is wrong and I am talking about injecting methods to old objects. I have no problem admitting when I am wrong but in this case maybe I was not clear enough considering I am responsible for exploding this thread , I hope in a good way. So yes its possible to do in Python but no it is not coming already available to you, so you can restrain yourself from abandoning Pharo for Python ;) Python is not there yet. I still keep the opinion that is easy to do , method injection is just regular assignment, you cannot get any easier than assignment but this means you have to keep track of the instances of a class and repace their methods. The good news is that if you replace just the methods and not the entire object , you can keep the references to the old instance because keeping track of the references as well would be trickier. So this way you would not brake your references and having to rebuild them to point to a new instance because you continue to use the old instance but with updated methods. You can do this also with adding / removing / editing variables and/or methods. So it does have a wide application. Python can give you back the references to and from an object (via gc module) but the problem is that when an object is created its already referenced by many internal stuff so it can get messy soon. Plus Python is not exactly a high performance language , unless you use third party libraries focusing on performance (basically C libraries wrapped for Python). In my case its easy to do because I care about live coding my own project and do not care about code outside of it, because I wont be changing it anyway. But if I had to do this the Pharo way , providing a full live enviroment it would be easy because I would have to find a mechanism to accomodate for tons of Python code that does not follow live coding standards by a long margin. So my goal is not to come up with full blown live coding enviroment like Pharo does, that is simply not possible because there is like a ton of python code out there and I am sure there so many scenarios that live coding in python can go wrong that I am not even aware of. But if live code is only for my code and my code alone , I dont think I will have any major issues. Afterall even when I use Pharo I use live coding strictly for my code and rarely touch the enviroment with the exception of once messing with UI theme classes. But then again I am so new to this that at any point I may come up for a solution about this too, who knows :) On Wed, Oct 11, 2017 at 7:05 PM Pierce Ng <[hidden email]> wrote: On Sat, Oct 07, 2017 at 01:41:17AM +0000, Dimitris Chloupis wrote: |
Re: Behold Pharo: The Modern Smalltalk
|
|
major mistake i meant to say "providing a full live enviroment it would NOT be easy because I would have to find a mechanism to accomodate for tons of Python code that does not follow live coding standards " On Wed, Oct 11, 2017 at 8:08 PM Dimitris Chloupis <[hidden email]> wrote:
|
Re: Behold Pharo: The Modern Smalltalk
|
|
In reply to this post by Offray Vladimir Luna Cárdenas-2
Well there is a move towards Pillar for class and method commands so who knows maybe we will have that soon enough ;)
There is a solution, not a great solution but it can do this. You can kinda do this via metacello and filetree, because when you export to git , it coverts class and method comments to markdown that can be viewed like online documentation . They are saved as README.md which is the standard for github. That means you can use markdown inside the class and method comments , and then convert that to HTML . Tons of markdown to html coverters out there so it would not be a problem. Of course Pharo users may not be happy to read comments in markdown but then markdown has minimal syntax so it should not be such a major issue. The real problem is the class comments itself, if you lack comments talking about automated API reference documentation sounds the least of the problems. Cannot blame developers, documentation is as much work as writting the code and I can understand that some may find it much less pleasant than I do :) I tried my best to help on the documentation department but we need more people because its an effort not only to document but also to keep the documentation updated. One of the perk working in an enviroment improving very fast, but you wont get any complain from me about this ;) On Wed, Oct 11, 2017 at 6:02 PM Offray Vladimir Luna Cárdenas <[hidden email]> wrote:
|
|
|
In reply to this post by kilon.alios
On Thu, Oct 12, 2017 at 1:08 AM, Dimitris Chloupis <[hidden email]> wrote:
This is what Smalltalk gives you for free.
So while Python has the flexibility for you to program such a system yourself, you don't get it for free like Smalltalk.
Smalltalk handles this for free. You need #become: Note one of the comments links to user code that apparently does the same thing in Python. But again this is Python "allows" you to, not "Python" gives it to you, but it could be good enough for you.
We now have this for improved performance...
And how does such C libraries impact your live coding? Its not longer turtles all the way down (or its turtles walking off a cliff) Of course, the same applies for FFI with Pharo, and one of the reasons that Smalltalk historically has been view as insular, living in its own world avoid using non-Smalltalk libraries - because the lose of live coding here is a big impact. cheers -ben
|
Re: Behold Pharo: The Modern Smalltalk
|
|
In reply to this post by Offray Vladimir Luna Cárdenas-2
Just to lead this back to the original
question. What you say is undoubtedly true. It is not, however,
necessarily something that a beginner will understand or be able
to share in. So, to a certain degree this may be a trap caused by
having the excellent environment. The newbie who is not used to
it and tries to get somehow organised before diving in will be
scared off.
(I do realise that this is a matter of the time being available, but the fact remains that people coming from the outside may be held back this apparent lack of information, even though it is only a lack of information external to the image. It's the difference between the converted who are already going with the flow and those who want to dip a toe into the water.) On 12/10/17 01:09, Offray Vladimir Luna Cárdenas wrote:
|
Re: Behold Pharo: The Modern Smalltalk
|
|
In reply to this post by Ben Coman
Sorrry for being rude but I wll use the two usually heavily annoying word, at least for me :D It depends See there is a problem for Python here. Ideology. The zen of python has been both a joke a serious mantra in the python world . Its a joke because its obviously oversimplify decision making in such a complex subject as language designe but is serious because it clearly illustrates the philosophy of its creator, Guido van Rossum. Guido is not any less of a rock star to Pythoners than Alan Kay is for Smalltalkers. The zen has become so popular that is even included in python implementation and can be fetched as the link says using the "import this" in any implementation of Python. It's the very sould of python as messages and objects are the very soul of Smalltalk. So the problem here is that a live coding enviroment brakes the second rule. "explicit is better than implicit". Because live coding in Pharo and Smaltalk is about replacing old instances with new while keeping the state it non the less an implicit behavior and especially become is a no go scenario for python because not only replaces references to an object it also breaks the references to the other object. Of course the old object is garbage collected and RIP. Python follows this rule very strictly. Thus means that not only that Python will not offer a live coding enviroment in the future as the basis of its implementation . It means it does not want to. It may offer it as part of its extensive library. That also leads us to the inescapable conclusion that nothing comes free, everything has a cost. Because there will be scenarios you dont want to lose your old instances or not affect them at all and instead affect only the classes or maybe you dont even want to do that and want to do something else.
First the python example is not an actual become the way I understand it, because not only it does not change the references to the object , it exchanges only the variables not the methods __CLASS__ is reference to the class object. __DICT__ is a reference to the instance object dictionary contains basically the names of the variables but not references to the methods themselves . Which means this wont work for live coding. His example works because both classes share the same methods with same code in them but we know this is the polar opposite of live coding. You can get references to the modified methods using this code my_class_ref = (globals()[self.__class__.__name__]) found_methods=[eval("my_class_ref()." + entry,{'my_class_ref':my_class_ref}) for entry in dir(my_class_ref()) if eval("type(my_class_ref()." + entry + ").__name__",{'my_class_ref':my_class_ref}) == 'method'] Globals is used to fetch the reference to the class object. eval is used because names are passed as strings of course and basically eval executes a string as a collection of python commands and returns its value. In this case the value is a reference to an object, a method object. Dir returns all names , including both variables and methods, instance and class, including all superclasses. You do then something similar to get the old methods , and then you iterate checking the names and replacing the references with simple assignments. You end up with a become that is I would say around , if I brake down the list comprehension to multiple lines, 20 lines of code. It wont be still a Smalltalk become but it will support live coding and live replacement of instance objects.
Here come the two ugly words "it depends" See what the python becomes does is essentially better than the smalltalk becomes. I know its hard to not throw tomatoes at me but if you take a closer look at the Elito's paper you linked you will see why. Python solution really becomes an object to another because its swaps its contents and not the entity of the object, this includes variables and methods and the class it points to. By entity here I mean its place in memory and by you I mean the person implementing the VM. In Smalltalk becomes is not really become but rather replaceReferences , because it brakes the references to the object and then replace them with references to another object. Unfortunately this creates problems because you have to find to references to the objects and that comes with a cost if thousands of things reference it. Hence why Eliot had to optimise this. But python solution has no cost because you dont have to change the references to the object. And references to the members of an object (variables and methods) have to pass through the reference to the object itself. So python in this cases does not have to optimise,because it deals with a lot less references.. Smalltalk has to. Why Smalltalk does it this way, I do not know , this is VM territory and clearly Eliot outranks me to a great degree on the subject of VM design but I am sure there is a technical reason.
Sorry I cannot resist :D It depends Technically speaking your are wrong not only for Python but also for Pharo too. The reason being that even in the case of imported c functions they are wrapped inside objects. So it is indeed turtles all the way down. At least to the function level. The arguments passed to the c functions itself are also objects, the access to the memory also objects, pointers are also objects. C data types also object. Of course you need VM primitives to make the actual calls but those are wrapped into objects. So yes the room is full of turtles and there is no escape for you :D Python goes an extra step with its Python C API. This is an API used to build a DLL that is compatibe with Python. Essentially Python then can import this DLL as if it was a python source code file and use it as such. Most of the Python third party libraries use this approach. Cython also uses this approach too. The API forces you to use PyObject which is a C function that wraps a C function around a Python object. So when you access it from Python its now an object. Also remember that in Python , python functions are object too. So there is no escape. I have no idea how Pharo VM does this, I know it supports plugins in a similar function and I suspect that it forces you to wrap then in Smalltalk objects at least at bytecode level but no clue if that is the actual case. Again the experts can jump in and enlighten us. Of course wrapping the C function to be called as an object does not mean that you will wrap all the functions called by the C function. If those C functions are not meant to be used by the user then they wont be objects but they will also not be accessible. Always talking about Python C API. Talking about FFI, whether Pharo (UFFI) or Python (ctypes) there is no way around object creation that I am aware of. So you cannot avoid objects even if you want to. Of couse those object does not necessarily mean they offer you all your usual comfort , they may come with some small letter disclaimers but then we go back to the never ending "it depends" rabbit hole.
|
Re: Behold Pharo: The Modern Smalltalk
|
|
"one of the reasons that Smalltalk historically has been view as insular, living in its own world avoid using non-Smalltalk libraries - because the lose of live coding here is a big impact."
I would not say that Smalltalk is viewed as insular. I would say that Smallalk is not viewed at all period. Pharo wise the people who introduced to Pharo have been impressed by it. The same way most Pharoers prefer pharo libraries to c libraries via UFFI , applies to python coders as well. You think a python coder is eager to leave the comforts of his language, think again. In both communities its user with either C experience or motivated to learn C for personal reasons that use the FFIs or other means to import C code. Is it an accident that 99% of C wrapped code libraries for Python are existing C projects ? Some existing for decades and predating Python. A pure Python developers will be as unlikely to use the FFI as a Pharo developer, and by developers I mean users not the people who actually develop Pharo. So no there is nothing wrong with Smalltalk and Smallalk works with C just fine. Python's C API gained quickly reputation among the C people of being easy to us so Python became the go to language for scripting C. This is also why Python offered embeding, because back then Python was slooowwww. This led Guido to claim that Python may be a great choice for scripting C project but choice for replacing high performance code. He did not even intended the language to target anything else than scriptin. Nonetheless that did not stop the community from pop up like mushrooms high performance libraries to that extend that nowdays Python is regarded as the second best choice for high performance computing after C/C++ which if you think about it sounds kinda insane but non the less wrapped optimised C python libraries can easily outperform non optimised C/C++ code. An example being the emarashing truth that Python strings are faster than C++ strings which forces C++ coders to use an external library that optimised them called Boost. So the real irony is that back then embeding Python was recommended, nowdays embdeding Python is frown upon. Instead now its recommended to brake your C project to a library wrapped for Python and import it to Python. Its fascinating to see something that started so humble become so ambitious but that is true power of the community and this is also the true power of Pharo. You can let this misconceptions get in the way and think small like "Python/Pharo cannot do this, or is hard to do" or you can shut up (something I find hard to do) and just do it. As I said , we use only 0.0000001% of the potential of any language out there. |
Re: Behold Pharo: The Modern Smalltalk
|
|
In reply to this post by kilon.alios
2017-10-12 9:28 GMT+02:00 Dimitris Chloupis <[hidden email]>:
Hm, we have our own Pharo Zen, which includes a Explicit is better than implicit. So we are violating our own (zen)rules :) in my point of view, live or interactive coding has not much to do with explicit or implicit program code. |
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |