The point is that pharoers should implement the vision not pharo. We have enough to do. The fact that pharo will succeed depends also on us as a community nor just 5 guys doing an integration of fixes.
Stef > Stef, > > I understand you agree with Mariano. Now how will Pharo fulfill > this vision? > > -- > > Cesar Rabak > > PS.: See also my reply to Mariano > > Em 16/08/2009 06:12, Stéphane Ducasse < [email protected] > > escreveu: > > > +1 > > On Aug 15, 2009, at 1:42 AM, Mariano Martinez Peck wrote: > > > > > > > 2009/8/14 > > > > 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 ac cess 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) neithe r 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 > > 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 impos sible. 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 appro ach 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/w iki/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 > > > _______________________________________________ > 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
