> > - 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 >
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.
