Hi,
Shiny for the R language is a very useful technique to create responsive applications based on Web technologies - with all the advantage the big ecosystem of JS libraries offers. With Shiny in mind, I’m working with Teapot on Pharo. Dashboard like use interface with Processing (exactly: p5.js) and other things is in mind. From my job, I do a similiar thing. But because of our IT policy, I have to work with Python (using Tornado server and Dash) and SignalR for Microsoft .Net (exactly: ASP.net) So I can compare. And if I remember the work with Pharo many years ago, I can state the following: - The Microsoft Visual Studio offers a lot. It has many functions, assistants, components and libraries and a huge bunch of documentation which support to concentrate on the problem. Details are hidden, and even deployment is a matter of minutes. But this professionallity has the downsize of complexity, and to understand whats going on is not always easy. But if you manage this complexity you can get professional apps in a reasonable time. - Python is flexible and dynamic. I use the Anaconda distribution with Spyder which has good support for interactivity and debugging. Many libraries of good quality are available in the python world, you can tackle any problem. Also here: support professional software development in good time is given. A little bit more than Microsoft, the Python things are more understandable and more lightweight. Pharo, in its incarnation today (6.1) comes very near to this. Also Pharo has many libraries, a good to use „IDE“ and professional tools for debugging and profiling. BUT: Pharo is far more transparent. The interactivity and the availability of every sourcecode in combination with the debugging capabilities inherent to Smalltalk are helping to understand every thing. And Pharos today documentation address now relevant but not to complicated problems, cover all important tools and libraries and supports starting at beginner level. Pharo has lost the nature of a expert or nerd secret magic wizard tool. In this direct comparison, I had some wishes for the future of Pharo: - Deployment: it should be possible to deploy a „single click“ application, independet if native GUI or Web App or Shiny like - More standard solutions: many libraries have examples, but they are sometimes to trivial or just irrelevant for daily practice - More product oriented: libraries should have more wizzards or application pattern. Imaginary example: for Teapot or Seaside would it be fine if there were some code generator for a 4 Tile dashboard app, or a data viz app, themes like in hugo or bootstrap. I may be wrong, but the nature of many libraries or tools is „make anything possible“ instread of „I help you to write your product“. Do you understand what I want to say ? Anyway. I can state: Phare IS on the right way. It is. Much much progress the last years. Thank you all ! And if it becomes more and more a product for professionals (in industry), the future will be top ! And this doesnet mean to give up the computer science part. Pharo is cool to try concepts and ideas. So Pharo has BOTH sides, which does it make great. Cheers Hans |
Thanks for your report Hans.
With Grafoscopio[1] I want to provide a "product/app" instead of a library (of course it can exists because of the excellent libraries Pharo ecosystem is providing) that bridges the gap between user/developer and expert/novice. Still its community is nascent and I have some reports of interest/use in this community and locally, but co-development is yet far away, I think. [1] http://mutabit.com/grafoscopio/index.en.html So yes, Pharo is pretty empowering and it has the proper direction and it is increasing in momentum, but still we need to traverse a long path to enlarge the ecosystem and made it more "end user" friendly by offering more "end user" apps made with Pharo & friends. Cheers, Offray On 22/11/17 18:23, Hans N Beck wrote: > Hi, > > Shiny for the R language is a very useful technique to create responsive applications based on Web technologies - with all the advantage the big ecosystem of JS libraries offers. > With Shiny in mind, I’m working with Teapot on Pharo. Dashboard like use interface with Processing (exactly: p5.js) and other things is in mind. > From my job, I do a similiar thing. But because of our IT policy, I have to work with Python (using Tornado server and Dash) and SignalR for Microsoft .Net (exactly: ASP.net) > > So I can compare. And if I remember the work with Pharo many years ago, I can state the following: > > - The Microsoft Visual Studio offers a lot. It has many functions, assistants, components and libraries and a huge bunch of documentation which support to concentrate on the problem. Details are hidden, and even deployment is a matter of minutes. But this professionallity has the downsize of complexity, and to understand whats going on is not always easy. But if you manage this complexity you can get professional apps in a reasonable time. > > - Python is flexible and dynamic. I use the Anaconda distribution with Spyder which has good support for interactivity and debugging. Many libraries of good quality are available in the python world, you can tackle any problem. Also here: support professional software development in good time is given. A little bit more than Microsoft, the Python things are more understandable and more lightweight. > > Pharo, in its incarnation today (6.1) comes very near to this. Also Pharo has many libraries, a good to use „IDE“ and professional tools for debugging and profiling. BUT: Pharo is far more transparent. The interactivity and the availability of every sourcecode in combination with the debugging capabilities inherent to Smalltalk are helping to understand every thing. And Pharos today documentation address now relevant but not to complicated problems, cover all important tools and libraries and supports starting at beginner level. Pharo has lost the nature of a expert or nerd secret magic wizard tool. > > In this direct comparison, I had some wishes for the future of Pharo: > > - Deployment: it should be possible to deploy a „single click“ application, independet if native GUI or Web App or Shiny like > - More standard solutions: many libraries have examples, but they are sometimes to trivial or just irrelevant for daily practice > - More product oriented: libraries should have more wizzards or application pattern. Imaginary example: for Teapot or Seaside would it be fine if there were some code generator for a 4 Tile dashboard app, or a data viz app, themes like in hugo or bootstrap. I may be wrong, but the nature of many libraries or tools is „make anything possible“ instread of „I help you to write your product“. Do you understand what I want to say ? > > Anyway. I can state: Phare IS on the right way. It is. Much much progress the last years. Thank you all ! And if it becomes more and more a product for professionals (in industry), the future will be top ! And this doesnet mean to give up the computer science part. Pharo is cool to try concepts and ideas. So Pharo has BOTH sides, which does it make great. > > Cheers > > Hans > > > > > > > |
In reply to this post by Hans
- Deployment: it should be possible to deploy a „single click“ application, independet if native GUI or Web App or Shiny like if by single click you mean you press a button and an application is created , technically with pharo you dont even need to push a button, as pharo is already an application. Pharo is not an IDE, is not a language, is not a virtual os , or a live coding enviroment. Its simply an application that fullfils all these roles.You may say "so what, everything is an application" , well not quite because Pharo is an application practically written in itself offering you direct access to all its internal making it completely customisable. Even its VM can be customised from inside Pharo which if you think about it, other languages would consider this a form of insanity and to a point they are correct to do so. Thus there is no point of creating standalone applications with Pharo because this goes against its very ideology of IDE, most IDEs nowdays miss the I, standing for Integration which means that you integrate development tools, plus language plus your code in one thing. These things are not used merely to create the application they are meant to be included with the application you create. I usually say to people that they have no clue what integration means until they coded in Smalltalk. Smalltalk is just light years ahead in that departmen and so is Pharo. A standalone application rips these things apart , its the seperation between development builds and release builds that are far less meaningful for Pharo and you will rarely read about them in this mailing list. The actual problem of Pharo is the sever lack of documentation. Its much better nowdays than it used to but the fact remains that biggest weakness of Pharo is that it moves about 1000 times faster than its documentation. This is one huge disadvantage of a very productive/ succesful development enviroment. Python which is a language I also regularly use on daily basise, its a language that barely changes wtih each version. The only singificant change for Python was Python 3 and even that pales in comparison to the massive changes we see in each Pharo version. The next version of Pharo for example may have a completely new GUI API , that is something you rarely see happening to a language. This is ok because Pharo obviously is not a programming language and neither is Smalltalk. On the matter of standalone applications , Pharo offers a masive degree of customisation that is unknown even amongst its most experienced users. Pretty much anything you see and dont see is customisable. So ironically Pharo offers a much larger degree of efficiency for generating standalone applications than any IDE or language out there , or even third party tool. By standalone in this case I mean application that execute by themselves without even a need to be installed. The reason for this, is the same reason Pharo is so extremely productive. Its not the live enviroment, its not the pure OOP, its not the IDE, or the simplicity of the language. Its the I, Integration. No language or IDE , however much more powerful it may seem can ever come close to competing with Pharo. That does not make Pharo the best choice, just the most flexible. In the end the fact that Pharo evolution is thousands times faster than its documentaiton is a very solid reason not to use Pharo and not to recommend to others. Because in the end documentation is extremely important. But this is one of those scenarios of not having your cake and eating too. With Pharo you choose to sacrifice documentation for high coding productivity. Of course lack of documentation hinders productivity but that is only temporarily until you learn what you want to learn. But then learning what you want make take years if not decades. To explain how one can create a standalone application with Pharo in full detail is to explain the entire Pharo in full detail. This is why articles that have been written in the past just barely scratch the surface and tend to give the opposite impression. Bottom line if you come to Pharo for wizards, documentation and generally hand holding attitude , go back to Python. Python is excellent at this role and is practically untouchable by its competition which is why it is considered the king of "ease of use". Pharo is the exact opposite, its difficult , frustration, annoying, messy and extremely manual. But if you search for most the powerful and flexible development enviroment in the world. Nothing comes remotely close to Pharo. Pharo is the undisputed king of Integration. It will blow your mind like a nuclear explosion of how extremely customisable it is. Which lead to the inate question what makes one more productive the Python or the Pharo ideology ? My answer is that Python offers more productivity in the short run (which is why is No 1 if not the only recommended language for beginners to coding) but in the long run after extensive study of the Pharo enviroment , which means reading tons upon tons of code (it sucks I know, especially when you realise that not even classes have comments), Pharo is the clear winner. As soon as you eliminate the need for documentation and wizard like attitude Pharo moves at the speed of light. There is an effort to make Pharo more Pythonic, but to be sincere, Pharo will always be Pharo and personally I do not like to hide Pharo shortcoming as I do not like to to hide its strenghts. Pharo essentially does not care about other languages, because its not a language. Pharo essentially does not care about IDEs, because its not an IDE. Pharo essentially does not care about wizards, because its not wzard. Pharo's charm is that it has the courage to say "I do not care , I will do things my way" and just push forward. So you could say Pharo is the very definition of acquired taste. Its not so much about being better and more about being diffirent. Which is a breath of fresh air in the world that everybody copies everybody else. So my advince to all newcomers is that if you are here for the right reasons and ready to commit to the Pharo ideology, arm yourself with massive amount of patience and march on. It will be a bumpy but extremely rewarding ride and completly change the way you think about coding and especially about OOP. |
+1000
Sent from my iPhone
|
In reply to this post by Hans
Hi hans
Thank you for this analysis. Now do you want me to state a question? Stef On Thu, Nov 23, 2017 at 12:23 AM, Hans N Beck <[hidden email]> wrote: > Hi, > > Shiny for the R language is a very useful technique to create responsive applications based on Web technologies - with all the advantage the big ecosystem of JS libraries offers. > With Shiny in mind, I’m working with Teapot on Pharo. Dashboard like use interface with Processing (exactly: p5.js) and other things is in mind. > From my job, I do a similiar thing. But because of our IT policy, I have to work with Python (using Tornado server and Dash) and SignalR for Microsoft .Net (exactly: ASP.net) > > So I can compare. And if I remember the work with Pharo many years ago, I can state the following: > > - The Microsoft Visual Studio offers a lot. It has many functions, assistants, components and libraries and a huge bunch of documentation which support to concentrate on the problem. Details are hidden, and even deployment is a matter of minutes. But this professionallity has the downsize of complexity, and to understand whats going on is not always easy. But if you manage this complexity you can get professional apps in a reasonable time. > > - Python is flexible and dynamic. I use the Anaconda distribution with Spyder which has good support for interactivity and debugging. Many libraries of good quality are available in the python world, you can tackle any problem. Also here: support professional software development in good time is given. A little bit more than Microsoft, the Python things are more understandable and more lightweight. > > Pharo, in its incarnation today (6.1) comes very near to this. Also Pharo has many libraries, a good to use „IDE“ and professional tools for debugging and profiling. BUT: Pharo is far more transparent. The interactivity and the availability of every sourcecode in combination with the debugging capabilities inherent to Smalltalk are helping to understand every thing. And Pharos today documentation address now relevant but not to complicated problems, cover all important tools and libraries and supports starting at beginner level. Pharo has lost the nature of a expert or nerd secret magic wizard tool. > > In this direct comparison, I had some wishes for the future of Pharo: > > - Deployment: it should be possible to deploy a „single click“ application, independet if native GUI or Web App or Shiny like > - More standard solutions: many libraries have examples, but they are sometimes to trivial or just irrelevant for daily practice > - More product oriented: libraries should have more wizzards or application pattern. Imaginary example: for Teapot or Seaside would it be fine if there were some code generator for a 4 Tile dashboard app, or a data viz app, themes like in hugo or bootstrap. I may be wrong, but the nature of many libraries or tools is „make anything possible“ instread of „I help you to write your product“. Do you understand what I want to say ? > > Anyway. I can state: Phare IS on the right way. It is. Much much progress the last years. Thank you all ! And if it becomes more and more a product for professionals (in industry), the future will be top ! And this doesnet mean to give up the computer science part. Pharo is cool to try concepts and ideas. So Pharo has BOTH sides, which does it make great. > > Cheers > > Hans > > > > > > |
Hi Stef,
sure :) But just before let me comment the other posts: yes you’re right. Pharo and Smalltalk follows a different philosophy and therefore some common terms like „app“ and „ide“ doesn’t make sense or have to be reinterpreted. You can always say: look, I have a super cool concept, dive In but you have to forget every thing else. OR: I offer you a new concept, look how it can help you to solve daily tasks and getting jobs done. Both perspectives have value to me. And I don’t say Pharo should priories the one or other. But with my post, I’m taking the perspective of I need a tool to solve problems, in my given environment, my colleagues, my customers, my IT infrastructure, my constraints. Pharo is well in being the superior new concept. We know that. All what I want give you, the Pharo experts the feedback that I’m very happy them that Pharo is on the way for having value for the other perspective, a tool for solving problems in daily work. Not more not less. Cheers Hans > Am 23.11.2017 um 09:54 schrieb Stephane Ducasse <[hidden email]>: > > Hi hans > > Thank you for this analysis. > Now do you want me to state a question? > > Stef > > On Thu, Nov 23, 2017 at 12:23 AM, Hans N Beck > <[hidden email]> wrote: >> Hi, >> >> Shiny for the R language is a very useful technique to create responsive applications based on Web technologies - with all the advantage the big ecosystem of JS libraries offers. >> With Shiny in mind, I’m working with Teapot on Pharo. Dashboard like use interface with Processing (exactly: p5.js) and other things is in mind. >> From my job, I do a similiar thing. But because of our IT policy, I have to work with Python (using Tornado server and Dash) and SignalR for Microsoft .Net (exactly: ASP.net) >> >> So I can compare. And if I remember the work with Pharo many years ago, I can state the following: >> >> - The Microsoft Visual Studio offers a lot. It has many functions, assistants, components and libraries and a huge bunch of documentation which support to concentrate on the problem. Details are hidden, and even deployment is a matter of minutes. But this professionallity has the downsize of complexity, and to understand whats going on is not always easy. But if you manage this complexity you can get professional apps in a reasonable time. >> >> - Python is flexible and dynamic. I use the Anaconda distribution with Spyder which has good support for interactivity and debugging. Many libraries of good quality are available in the python world, you can tackle any problem. Also here: support professional software development in good time is given. A little bit more than Microsoft, the Python things are more understandable and more lightweight. >> >> Pharo, in its incarnation today (6.1) comes very near to this. Also Pharo has many libraries, a good to use „IDE“ and professional tools for debugging and profiling. BUT: Pharo is far more transparent. The interactivity and the availability of every sourcecode in combination with the debugging capabilities inherent to Smalltalk are helping to understand every thing. And Pharos today documentation address now relevant but not to complicated problems, cover all important tools and libraries and supports starting at beginner level. Pharo has lost the nature of a expert or nerd secret magic wizard tool. >> >> In this direct comparison, I had some wishes for the future of Pharo: >> >> - Deployment: it should be possible to deploy a „single click“ application, independet if native GUI or Web App or Shiny like >> - More standard solutions: many libraries have examples, but they are sometimes to trivial or just irrelevant for daily practice >> - More product oriented: libraries should have more wizzards or application pattern. Imaginary example: for Teapot or Seaside would it be fine if there were some code generator for a 4 Tile dashboard app, or a data viz app, themes like in hugo or bootstrap. I may be wrong, but the nature of many libraries or tools is „make anything possible“ instread of „I help you to write your product“. Do you understand what I want to say ? >> >> Anyway. I can state: Phare IS on the right way. It is. Much much progress the last years. Thank you all ! And if it becomes more and more a product for professionals (in industry), the future will be top ! And this doesnet mean to give up the computer science part. Pharo is cool to try concepts and ideas. So Pharo has BOTH sides, which does it make great. >> >> Cheers >> >> Hans >> >> >> >> >> >> > |
Just to clarify, you will never read from me that Python or Pharo is superior or what else. Superior and better is highly subjective and depends obviously on your needs and specific problem you want to solve. What I am saying , is yes I am perfectly ok and even encourage Pharo offering similar functionality we come to expect from other IDEs, languages, third party tools etc . There is definetly a lot of value in offering something that is easier to learn and an easier way of doing things. The essense of computers is to automate stuff. But like any other language, IDE, third party tool etc Pharo attracts a specific kind of people. Python attracts people that want the easiest learning curve possible C attracts people who want the highest performance code possible Pharo attracts people who want a highest productivity workflow with full customisability. Which one is best ? Hmm.... highly debatable, which is why language wars end to up nowhere. Its not that Pharo cannot be fast, or easy to learn, its not that C cannot be easy to learn and fully customisable and highly productive and its not that Python cannot be top performance or highly productive and full customisable. But each one has its own priorities and life is all about priorities. On the matter of application deployment to offer you some recommendations What you can do 1) Rename the executable, which basically contains the VM 2) Change the icon of the executable 3) Create a startup script , if you want to have some kind of default behavior when the user first opens Pharo or each time it opens it 4) Use attached morphs to world, these morphs cannot be resized, take the entire space of pharo window and block any interaction with the Pharo ide. When you dont not want your user to access your application internals. 5) Morphic offers themes you can use to add a special touch to your interface even making it look more native 6) There is no need for an installer but if you want to create one because of dependencies that are shared among application you can use any third party tool that can be used for any other language , nothing special here 7) You can offer automatic updates via git, Metacello gives a lot of access to git functionality so you can connect to your git repo , check the latest version and redowload the source in the background using a fork process 8) you can use makefiles with Pharo for generating diffirent builds for your application, again you can use pharo startup scripts to automatically install code to a freshly build image. 9) The help tool can be used as internal documentation of your image 10) If you want a cheap way to crate a multi core application, you can trigger multiple instances of pharo and let them talk with each other via sockets. Each istance will be assigned by OS to a separate core 11) If you must absolutely have a native interface run pharo without its ui (this happens with the use of pharo.exe instead of pharo-ui.exe ) and use the UFFI to generate your interface using the the native interface of your OS. This of course will make your application non cross platform but is still a popular choice for mosr desktop applications 12) Its also possible use HTML/JS as GUI for Pharo, again you can use a web engine, like WebKit and UFFI 13) Ask questions here for anything, never hesitate 14) If all fails you can always use Pharo together with other languages, again using sockets, or shared memory, or pipes, Pharo gives you full access to your OS and the OS offer many ways for communication between process / applications / executables. On Thu, Nov 23, 2017 at 11:09 AM Hans N Beck <[hidden email]> wrote: Hi Stef, |
My question is then the following:
How do you help? There is no little action. Any action is an action. And all together we get stronger. Do not expect everything from us. Join and have fun. Stef On Thu, Nov 23, 2017 at 11:01 AM, Dimitris Chloupis <[hidden email]> wrote: > Just to clarify, you will never read from me that Python or Pharo is > superior or what else. > > Superior and better is highly subjective and depends obviously on your needs > and specific problem you want to solve. > > What I am saying , is yes I am perfectly ok and even encourage Pharo > offering similar functionality we come to expect from other IDEs, languages, > third party tools etc . There is definetly a lot of value in offering > something that is easier to learn and an easier way of doing things. The > essense of computers is to automate stuff. But like any other language, IDE, > third party tool etc Pharo attracts a specific kind of people. > > Python attracts people that want the easiest learning curve possible > C attracts people who want the highest performance code possible > Pharo attracts people who want a highest productivity workflow with full > customisability. > > Which one is best ? Hmm.... highly debatable, which is why language wars end > to up nowhere. > > Its not that Pharo cannot be fast, or easy to learn, its not that C cannot > be easy to learn and fully customisable and highly productive and its not > that Python cannot be top performance or highly productive and full > customisable. But each one has its own priorities and life is all about > priorities. > > On the matter of application deployment to offer you some recommendations > > What you can do > 1) Rename the executable, which basically contains the VM > 2) Change the icon of the executable > 3) Create a startup script , if you want to have some kind of default > behavior when the user first opens Pharo or each time it opens it > 4) Use attached morphs to world, these morphs cannot be resized, take the > entire space of pharo window and block any interaction with the Pharo ide. > When you dont not want your user to access your application internals. > 5) Morphic offers themes you can use to add a special touch to your > interface even making it look more native > 6) There is no need for an installer but if you want to create one because > of dependencies that are shared among application you can use any third > party tool that can be used for any other language , nothing special here > 7) You can offer automatic updates via git, Metacello gives a lot of access > to git functionality so you can connect to your git repo , check the latest > version and redowload the source in the background using a fork process > 8) you can use makefiles with Pharo for generating diffirent builds for your > application, again you can use pharo startup scripts to automatically > install code to a freshly build image. > 9) The help tool can be used as internal documentation of your image > 10) If you want a cheap way to crate a multi core application, you can > trigger multiple instances of pharo and let them talk with each other via > sockets. Each istance will be assigned by OS to a separate core > 11) If you must absolutely have a native interface run pharo without its ui > (this happens with the use of pharo.exe instead of pharo-ui.exe ) and use > the UFFI to generate your interface using the the native interface of your > OS. This of course will make your application non cross platform but is > still a popular choice for mosr desktop applications > 12) Its also possible use HTML/JS as GUI for Pharo, again you can use a web > engine, like WebKit and UFFI > 13) Ask questions here for anything, never hesitate > 14) If all fails you can always use Pharo together with other languages, > again using sockets, or shared memory, or pipes, Pharo gives you full access > to your OS and the OS offer many ways for communication between process / > applications / executables. > > > > On Thu, Nov 23, 2017 at 11:09 AM Hans N Beck > <[hidden email]> wrote: >> >> Hi Stef, >> >> sure :) >> >> But just before let me comment the other posts: yes you’re right. Pharo >> and Smalltalk follows a different philosophy and therefore some common terms >> like „app“ and „ide“ doesn’t make sense or have to be reinterpreted. >> >> You can always say: look, I have a super cool concept, dive In but you >> have to forget every thing else. >> OR: >> I offer you a new concept, look how it can help you to solve daily >> tasks and getting jobs done. >> >> Both perspectives have value to me. And I don’t say Pharo should priories >> the one or other. But with my post, I’m taking the perspective of I need a >> tool to solve problems, in my given environment, my colleagues, my >> customers, my IT infrastructure, my constraints. >> >> Pharo is well in being the superior new concept. We know that. All what I >> want give you, the Pharo experts the feedback that I’m very happy them that >> Pharo is on the way for having value for the other perspective, a tool for >> solving problems in daily work. >> >> Not more not less. >> >> Cheers >> >> Hans >> >> >> > Am 23.11.2017 um 09:54 schrieb Stephane Ducasse >> > <[hidden email]>: >> > >> > Hi hans >> > >> > Thank you for this analysis. >> > Now do you want me to state a question? >> > >> > Stef >> > >> > On Thu, Nov 23, 2017 at 12:23 AM, Hans N Beck >> > <[hidden email]> wrote: >> >> Hi, >> >> >> >> Shiny for the R language is a very useful technique to create >> >> responsive applications based on Web technologies - with all the advantage >> >> the big ecosystem of JS libraries offers. >> >> With Shiny in mind, I’m working with Teapot on Pharo. Dashboard like >> >> use interface with Processing (exactly: p5.js) and other things is in mind. >> >> From my job, I do a similiar thing. But because of our IT policy, I >> >> have to work with Python (using Tornado server and Dash) and SignalR for >> >> Microsoft .Net (exactly: ASP.net) >> >> >> >> So I can compare. And if I remember the work with Pharo many years ago, >> >> I can state the following: >> >> >> >> - The Microsoft Visual Studio offers a lot. It has many functions, >> >> assistants, components and libraries and a huge bunch of documentation which >> >> support to concentrate on the problem. Details are hidden, and even >> >> deployment is a matter of minutes. But this professionallity has the >> >> downsize of complexity, and to understand whats going on is not always easy. >> >> But if you manage this complexity you can get professional apps in a >> >> reasonable time. >> >> >> >> - Python is flexible and dynamic. I use the Anaconda distribution with >> >> Spyder which has good support for interactivity and debugging. Many >> >> libraries of good quality are available in the python world, you can tackle >> >> any problem. Also here: support professional software development in good >> >> time is given. A little bit more than Microsoft, the Python things are more >> >> understandable and more lightweight. >> >> >> >> Pharo, in its incarnation today (6.1) comes very near to this. Also >> >> Pharo has many libraries, a good to use „IDE“ and professional tools for >> >> debugging and profiling. BUT: Pharo is far more transparent. The >> >> interactivity and the availability of every sourcecode in combination with >> >> the debugging capabilities inherent to Smalltalk are helping to understand >> >> every thing. And Pharos today documentation address now relevant but not to >> >> complicated problems, cover all important tools and libraries and supports >> >> starting at beginner level. Pharo has lost the nature of a expert or nerd >> >> secret magic wizard tool. >> >> >> >> In this direct comparison, I had some wishes for the future of Pharo: >> >> >> >> - Deployment: it should be possible to deploy a „single click“ >> >> application, independet if native GUI or Web App or Shiny like >> >> - More standard solutions: many libraries have examples, but they are >> >> sometimes to trivial or just irrelevant for daily practice >> >> - More product oriented: libraries should have more wizzards or >> >> application pattern. Imaginary example: for Teapot or Seaside would it be >> >> fine if there were some code generator for a 4 Tile dashboard app, or a data >> >> viz app, themes like in hugo or bootstrap. I may be wrong, but the nature of >> >> many libraries or tools is „make anything possible“ instread of „I help you >> >> to write your product“. Do you understand what I want to say ? >> >> >> >> Anyway. I can state: Phare IS on the right way. It is. Much much >> >> progress the last years. Thank you all ! And if it becomes more and more a >> >> product for professionals (in industry), the future will be top ! And this >> >> doesnet mean to give up the computer science part. Pharo is cool to try >> >> concepts and ideas. So Pharo has BOTH sides, which does it make great. >> >> >> >> Cheers >> >> >> >> Hans >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> > |
Me ? I don’t follow you, I am a member of this community since 2011 with active contributions to documentation, tutorials , promotion and improvement of Pharo. Much less now days because I am busy but still around offering advice and answers in mailing list and managing the Discord server. Does not that count as action ? On Thu, 23 Nov 2017 at 12:16, Stephane Ducasse <[hidden email]> wrote: My question is then the following: |
In reply to this post by Stephane Ducasse-3
Hi Stef,
my post is intended as feedback. Action is a different thing. Feedback may help to indentify useful actions. In this sense, I thought feed back is help, too. May be I'm wrong. If you thing feed back is useless and without value, and only "action" counts, then is this your opinion. Then I'll take my actions (which are there, I develop on TeaPot, as you could read) and be quiet. Full Stop. Hans -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html |
On 11/23/17, Hans <[hidden email]> wrote:
> Hi Stef, > > my post is intended as feedback. Action is a different thing. Feedback may > help to indentify useful actions. In this sense, I thought feed back is > help, too. May be I'm wrong. > > If you thing feed back is useless and without value, and only "action" > counts, then is this your opinion. Then I'll take my actions (which are > there, I develop on TeaPot, as you could read) Hello Hans You write "With Shiny in mind, I’m working with Teapot on Pharo" This is interesting. could you please elaborate on this, probably in a new thread? --Hannes and be quiet. Full Stop. > > Hans > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > > |
In reply to this post by Hans
Hans, feedback is probably one of the most crucial elements in improving software. So not only classifies as help in my book its up there on top.
Improvement for the shake of improvement is just pointless. Feedback helps show a common path that can keep users as happy as possible. Also note that we all express our own opinions here, none represents Pharo. At no point should you keep quite and not participate in the discussion. We are humans, not robots. Disagreement is part of the game and frankly this community in my 5 years being around has been more than welcomed to me and many others. I know because I tend to ask many stupid questions :D Plus the points you already discussed have already mentioned by many other people, so clearly there is a desire for improvement there. What Stef probably means is that he agrees with you and that the problem is not disagreement but rather that we do lack contributors to push those things forward. Which frankly I do not blame him, because he already has lifted by himself the vast majority of the documentation of Pharo. I used to be far more active, but alas I cannot be as active contributor to documentation as I used to. You are correct, there are glaring issues with Pharo, especially the way we expose the amazing set of features that Pharo has for customisability but then Stef is correct as well in that in the end it comes down to who is willing to contribute. That does not mean we do not appreciate feedback, its definitely very important. Code and documentation contribution is more important though. On Thu, Nov 23, 2017 at 12:54 PM Hans <[hidden email]> wrote: Hi Stef, |
Administrator
|
In reply to this post by kilon.alios
Dimitris, you have nailed it! I've long complained about Smalltalk development tools which prevent one from easily getting hands on the underlying objects (gui and domain model) to work directly with them. I've long complained about code tools that don't provide the functionality of the browsers. e.g. a difference tool that only has functionality limited to showing the differences. I've long complained about applications that don't do what I want and don't provide a powerful scripting language. Based on what you wrote, I would say that there is a reason to present an application which appears closed, but in reality still let's one get into the full development environment and work directly with it's underlying objects. So, my ideal application would start with only it's windows / UI, but which would easily allow me to open inspectors on the GUI instance or it's domain object and would easily allow me to open the full Smalltalk environment, too. (And to be able to close it back up to just the application UI once again.) THAT would be a powerful application! On Nov 22, 2017 23:58, "Dimitris Chloupis" <[hidden email]> wrote:
|
Administrator
|
(damned auto-correct! Please ignore the stupid apostrophes in "let's" and "it's" and any other I've missed.) On Nov 23, 2017 10:08, "Richard Sargent" <[hidden email]> wrote:
|
In reply to this post by Hans
Hi hans
No need to overreact. WE VALUE FEEDBACK. Now if people would understand that yes they can do a simple commit to recategorise a method. Then we could also focus on more important things. NOW FEEDBACK is great. Then what? Stef On Thu, Nov 23, 2017 at 11:53 AM, Hans <[hidden email]> wrote: > Hi Stef, > > my post is intended as feedback. Action is a different thing. Feedback may > help to indentify useful actions. In this sense, I thought feed back is > help, too. May be I'm wrong. > > If you thing feed back is useless and without value, and only "action" > counts, then is this your opinion. Then I'll take my actions (which are > there, I develop on TeaPot, as you could read) and be quiet. Full Stop. > > Hans > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > |
You see I documented for example how to use travis and bintray.
Super boring to turn a log into a pillar doc. And this way other people can use this doc. Do you know the Soup of Stones (check on wikipedia) ? Stef On Thu, Nov 23, 2017 at 11:40 PM, Stephane Ducasse <[hidden email]> wrote: > Hi hans > > No need to overreact. > WE VALUE FEEDBACK. > Now if people would understand that yes they can do a simple commit to > recategorise a method. > Then we could also focus on more important things. > > NOW FEEDBACK is great. Then what? > > Stef > > > On Thu, Nov 23, 2017 at 11:53 AM, Hans <[hidden email]> wrote: >> Hi Stef, >> >> my post is intended as feedback. Action is a different thing. Feedback may >> help to indentify useful actions. In this sense, I thought feed back is >> help, too. May be I'm wrong. >> >> If you thing feed back is useless and without value, and only "action" >> counts, then is this your opinion. Then I'll take my actions (which are >> there, I develop on TeaPot, as you could read) and be quiet. Full Stop. >> >> Hans >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> |
In reply to this post by Stephane Ducasse-3
yes please, keep feedback coming :)
(you and everybody). Esteban > On 23 Nov 2017, at 23:40, Stephane Ducasse <[hidden email]> wrote: > > Hi hans > > No need to overreact. > WE VALUE FEEDBACK. > Now if people would understand that yes they can do a simple commit to > recategorise a method. > Then we could also focus on more important things. > > NOW FEEDBACK is great. Then what? > > Stef > > > On Thu, Nov 23, 2017 at 11:53 AM, Hans <[hidden email]> wrote: >> Hi Stef, >> >> my post is intended as feedback. Action is a different thing. Feedback may >> help to indentify useful actions. In this sense, I thought feed back is >> help, too. May be I'm wrong. >> >> If you thing feed back is useless and without value, and only "action" >> counts, then is this your opinion. Then I'll take my actions (which are >> there, I develop on TeaPot, as you could read) and be quiet. Full Stop. >> >> Hans >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> > |
Free forum by Nabble | Edit this page |