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]<http://mce_host/[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]<http://mce_host/[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://../../../undefined/compose?to=Pharo> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected]<http://../../../undefined/compose?to=Pharo> >> 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
