IMHO Pharo must stick to the roadmap milestones, keeping clear boundaries on what goes in and out - I value that some people are acting as gatekeepers.
Then a second community, those who develop frameworks that run on top of Pharo, like the authors of frameworks of Seaside, Glorp,,SqueakDBX (to name a few coming from the top of my head) may probably try to ensure their frameworks progresses aligned with the Pharo releases, demanding a rrobust and performant Smalltalk system impementattion. Now, to boost Pharo adoption, beyod smalltalkers, and to capture the attention of new people, probably not familiar with the language, technology, style, the system itself, the paradigm, and (why not) the culture,, a new foundation of spin-off should address the level of effort to envision and manufacture... #1 a rich set of widgets and #2 recipes showing how to combine them to produce high-impact realtime client GUIs As an example I mention what - Swing, AWT and SWT is for Java, - Tk is for Tcl, - GTK+ to C++, (and lots of....) - UIPaainter to VisualWorks, and so on..:) -----Mensaje original----- De: [email protected] [mailto:[email protected]]en nombre de [email protected] Enviado el: Sábado, 15 de Agosto de 2009 01:04 p.m. Para: [email protected] Asunto: Re: [Pharo-project] ORM for Pharo -- ½ OFF Mariano, I can understand the goal be Pharo idea and goal as you post. What I'm trying to bring (and hopefully add to this discussion) is how can we arrive there. We need to narrow down the definition of "enterprise application" and see where Pharo can start to thrive. No all encompassing approach would work as notwithstanding how poweful and complete Pharo could become it will not be anytime soon. The notion that Pharo be not assotiated per se to any UI it is a strong (and I vote to maintain it) design goal but in order to push forward Pharo together with robust and clean implementation we'll need a lot of energy and effort to produce enough educational materials like tutorial, manuals, etc., it will be confusing all the time have an example that do not work in another minor variation of UI (to stay in a single topic). So I return to the point: we need to have more clear goals on what particular realm we see Pharo as feasible for enterprise development and be able to enumerate what are the advantages of Pharo versus the other approaches. Hope it is more explicit now ;-) Em 14/08/2009 20:42, Mariano Martinez Peck < [email protected] > escreveu: 2009/8/14 <[email protected]> Mariano, I agree (and I myself have been on the Research side getting answers similar to those ones) in fact I'll add another item to your list: -- They have an "architectural steering committee" that dictates use of some RDBS I've seen this even requiring some ERP used different database engine thas suggested by supplier. . . So if we want to compete with enterprise applications we need to get into some Enterprise: We're still thinkering with printing in Pharo (and this is PITA when attempting to be platform agnostic), so no Report Generator still, no matter how well you connect to a RDBS, any slightly above trivial example CRUD application will need this support. Our present set of widgets is sleek but still not as comprehensive as the other competing approaches, and we still have not created enough baseline to have an "echo system" so third parties can augment them as it happens now with Java, .Net and happened (and still as legacy updates) in Delphi and VB. So if the goal is to reach those enterprise trench we have to find some company that would profit of having [Pharo] Smalltalk as a primary language to customize or augment their system, as today (say as sake of example, SAP has ABAP but with Netweaver is going Java, and they competitors similar path). Let's think about this: historically some (comercial) Smalltalks allowed via OLE (a.k.a. COM, etc.) to access Microsoft Office features and do things similar as VB (in fact even Tcl and Python allow that), but what is the "productivity" of programmer that finds a tutorial or an example in VB and has to "translate" it to Smalltalk? As today can we enumerate what would be an advantage of doing something in Pharo instead of some "mainstream" language just to do some GUI painting CRUD application? I don't know if I understand you. The idea and goal behind Pharo is to have the open, free, clean and robust smalltalk that we were missing for years for commercial applications. At least that's my idea of Pharo. It must be a platform and a base where you can create tools in it and with both of them create real applications. In my opinion Pharo shouldn't be associated with a particular UI (web or desktop) neither to a persistence strategy. Pharo must be the base of all that. So then you can have differents alternatives: For UI's you can have PolyMorph and the UI Builder. For Web you can have Seaside and Aida/Web. But pharo is not coupled with any of them. You will then choose the solutions that best feets your needs. In summary, I would love to use Pharo as platform to build enterprise and commercial applications. No matter how do I persist or display my objects. Best, Mariano again my 0.01999.... Regards, -- Cesar Rabak Em 14/08/2009 16:57, Mariano Martinez Peck < [email protected] > escreveu: 2009/8/14 <[email protected]> Esteban, I'm comenting this on philosophical grounds. I understand the efforts to have SqueakDBX and other ORM in Pharo are motivated by Seaside and other "production" initiatives so, again, my food for thought is more an intellectual contribution which I see as useful for Pharo as project: I don't see Pharo any time soon® having all the toolset to be able to compete in the CRUD¹ realm with more streamlined tools and besides, not matter how much theoretical work has been done on ORM, the "impedance mismatch" is still there, Hi! I am agree with you about the "impedance mismatch". I think that if I am free to choose a persistence strategy I would use an OODB. However, if we are talking about real enterprise application (not a simple webpage) being able to choose the persistence strategy is practically impossible. We did a survey last year and the results were that most of the times you cannot choose. Of course, the client has a lot of reasons: - The client already has a RDBMS - They had paid for it and have the license (sometimes) - They want a company's support. The only company here is Gemstone. - RDBMS has history and it is an standard - They have knowledge about it - Interaction with other system (even legazy systems) - They are afraid of using another persistence strategy - They want to use SQL - They have DBAs - The persistence is difficult to negotiate So. In my opinion, if Pharo wants to be used really as a platform for enterprise applications (competing to java, .NET, etc), it must have a good relational solution. Of course, when you are able to choose, you can go for another approach like OODB. Best, Mariano a recent and practicall account of this (for Squeak) can be found in http://onsmalltalk.com/simple-image-based-persistence-in-squeak also, AIDA/Web has been able to run only storing thing in the image! See http://groups.google.com/group/comp.lang.smalltalk/browse_thread/thread/d3ba3867767b2253/f7435102b7e35ebe?lnk=gst&q=+pure+smalltalk+e+commerce%2C+no+rdbms%2C+no+apache%2C+smalltak+%2Blinux&rnum=1#f7435102b7e35ebe Since we'll increase the educational efforts to spread Pharo, I think that as technology we should to recover a bit of Smalltalk technology and be first more Object Oriented and then see if ORM still is so needed. my 0.0199999.... -- Cesar Rabak [1] http://en.wikipedia.org/wiki/Create,_read,_update_and_delete Em 14/08/2009 16:14, Esteban A. Maringolo < [email protected] > escreveu: My prototype is getting less proto, and I found out it doesn't have complex relations, and the system is going to perform faster if I have tables for most of it. What are the choices I have for doing ORM in Pharo? ¿Does GLORP work? ¿Any other options? I don't have a strong preference for the RDBMS engine, it can be anything (free), being it MySQL, PostgreSQL or Sql Server Express. Best regards, Esteban A. Maringolo _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
