> IMHO Pharo must stick to the roadmap milestones, keeping clear boundaries on
> what goes in and out - I value that some people are acting as gatekeepers.
>
> Then a second community, those who develop frameworks that run on top of
> Pharo, like the authors of frameworks of Seaside, Glorp,,SqueakDBX (to name
> a few coming from the top of my head) may probably try to ensure their
> frameworks progresses aligned with the Pharo releases, demanding a rrobust
> and performant Smalltalk system impementattion.
>
> Now, to boost Pharo adoption, beyod smalltalkers, and to capture the
> attention of new people, probably not familiar with the language,
> technology, style, the system itself, the paradigm, and (why not) the
> culture,, a new foundation of spin-off should address the level of effort to
> envision and manufacture...
> #1 a rich set of widgets and
> #2 recipes showing how to combine them to produce high-impact realtime
> client GUIs
>
> As an example I mention what
> - Swing, AWT and SWT is for Java,
> - Tk is for Tcl,
> - GTK+ to C++, (and lots of....)
> - UIPaainter to VisualWorks,
>
> and so on..:)
>
> -----Mensaje original-----
> De:
[hidden email]
> [mailto:
[hidden email]]En nombre de
>
[hidden email]
> Enviado el: Sábado, 15 de Agosto de 2009 01:04 p.m.
> Para:
[hidden email]
> Asunto: Re: [Pharo-project] ORM for Pharo -- ½ OFF
>
> 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.
>
> Hope it is more explicit now ;-)
>
> Em 14/08/2009 20:42, Mariano Martinez Peck <
[hidden email] >
> escreveu:
>
>
> 2009/8/14 <
[hidden email]>
>>
>> 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 <
[hidden email] >
>> escreveu:
>>
>>
>> 2009/8/14 <
[hidden email]>
>>>
>>> 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 <
[hidden email] >
>>> 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
>>>
[hidden email]
>>>
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>>
[hidden email]
>>>
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>>
[hidden email]
>>
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
>
> _______________________________________________
> Pharo-project mailing list
>
[hidden email]
>
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Locked
