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
