(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" <richard.sarg...@gemtalksystems.com> wrote: > 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" <kilon.al...@gmail.com> wrote: > > - 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. > > >
