2009/8/15 <[email protected]> > 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. >
I am totally agree. Would like to hear the board opinion. Hope it is more explicit now ;-) > Yes it was ;) > Em 14/08/2009 20:42, *Mariano Martinez Peck < [email protected] > >*escreveu: > > > > > 2009/8/14 <[email protected]<http://mce_host/[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]<http://mce_host/[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://../../../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
