> I agree, and my personal experience is that there is an issue in > companies when Perl gets ``too big for its boots'', this is > illustrated by the situation where many of the programmers have seen > the power of Perl and want to use it for the next big project, the CTO > in this fictional example will disagree as he has just been reading a great > report (probably sponsored by Sun) on how EJB's will save the world. > Now the Perl guys don't have anything to reply to this with. I think > this is one thing ``P5EE'' can address.
There is something sad about anyone thinking that anything will save the world, short of a whole lot of effort put in by a whole lot of hard-working, smart people. Regardless of the language that is used. And yet, this very sadness appears endemic. I know I've encountered it plenty of times. > For the record, at CTO level I do not believe it is enough to simply > say "Hey, its cool, we can grab some modules off CPAN and hack > something together that does the same as beans". I would tend to agree. > I think I tried to express this when I said that Perl/P5EE should work > with .Net etc. But you are right in bringing this up, taking messaging > as an example, the theoretical standard messaging system API may need > to be general enough to have a perl based perl-rpc solution as a backend > and also a JMS (Java Message Server) backend as well. I really don't > know how possible this is yet, but being a Perl project we should aim > to be all things to all men, "enterprise programming glue" and > "enterprise programming language of choice", if we fail at the later > we can always claim we only set out to do the first ;-) Thinking about Perl 6, now... Doesn't Gnat want for the Perl 6 compiler to emit Parrot, JVM and CLR opcodes? Might this not mean that we can simply (e.g.) code beans in Perl, and use beans other people give us fromm within Perl? How much of our problem might this solve? Beyond just being opcode compatible, I suppose that the other thing our work must do is conform to common, documented APIs. Maybe what we need is a kit of modules that helps us read those APIs, or helps us conform to them? > Evangelism at CTO level is something we cannot really address, For my fear-oriented goal, no. For your greed-oriented one, yes. Or at least, we bloody well better. CTOs can only choose between options they understand and are comfortable with. Unless we emit ecaps... er, sorry... unless we emit information to them in a way such that they a) receive it b) understand it c) get comfortable with it, then they'll never choose it. (Or maybe you just meant that there was a different squadron within the collected "we" who would be better suited for this job. Perhaps.) > we just > need to make sure the Perl ``enterprise level'' offering is good > enough so that when the ground troops come up against the > stereotypical CTO I've created, they have the ammunition. For a fear goal, it needs to work well. For a greed goal, it needs to appeal to CTOs, almost regardless of how well it works. (c.f. everything Microsoft has ever done.) > IIRC, Java > tried to use community based evangelism in the early days of Java, i > believe this has failed, after all I have never seen Java programmers > holding 100 dollar/50 quid (for 3 days) conferences. YAPC rocks. :-) I thought the one in Montreal this year was as at least as good as TPC this year. I would have made it out to the one in Amsterdam as well had I not a commitment to a conference in Seattle immediately following TPC. Cheers, Richard -- ---------------------------------------------------------------------------- Richard Dice ShadNet Creator * http://shadnet.shad.ca/ * [EMAIL PROTECTED] Occasional Writer, HotWired * http://www.hotwired.com/webmonkey/ "squeeze the world 'til it's small enough to join us heel to toe" - jesus jones
