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?
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,
Marianoa 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
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
