Today I find myself as a sofware engineer for a small company, working with about 3 or 4 other people in the engineering area. I am only one year out of college and perhaps I am naive. We built an object oriented application server that does everything that was required or requested of it before the more "seasoned" workers came on board. It is modular and extensible and very well designed.
The hot words seem to be "ubiquity", "encapsulation", and "Write once run everywhere".
Java has EJB, Jini, JDK's, Embedded Java, Personal Java, VM's, J2ME, and on and on and on...
I work with people who have industry experience of 20-30 years and they like the idea of buying the answers and simply "plugging them in."
When one of them looked at our solution he said to his friend "I can't believe they wrote their application in a 'glue' language." I have preached the good word of perl
and I might even say I've shown them that perl is a capable language for even large server side enterprise applications. And yet it is no Java...
My question, is can perl support a huge corporation? Does anyone think that perl reaches a threshold where it can no longer be looked at as meta-level of objects, services, and "beans"?
Has anyone sucessfully walked accross the line of midsize (tens of thousands of lines of code) application into the domain of huge business to business corporation while keeping perl's flexibility intact?
Could perl be turned into a VM kind of model? Will PalmPerl ever exist? Will perl byte code ever be viewed as an object that exports a clean well documented API for developers, or even
automated systems to make calls against?
These are the questions that keep me up at night.
UPDATE: I feel motivated to add... Should perl even try? Is there a benefit? If so how?
The truth is more important than the facts.
-Frank Lloyd Wright
RE: Can perl be anything like Java?
by merlyn (Sage) on Sep 19, 2000 at 23:33 UTC
|
My question, is can perl support a huge corporation? Does anyone think that perl reaches a threshold where it can no longer be looked at as meta-level of objects, services, and "beans"? Has anyone sucessfully walked accross the line of midsize (tens of thousands of lines of code) application into the domain of huge business to business corporation while keeping perl's flexibility intact?
Certainly. Etoys.com is all Perl. Deja is all Perl. Amazon.com uses Perl for nearly all their backend operations. Yahoo is mostly Perl behind the scenes. Altavista is all Perl, except for the purchased software. Sportsline.CBS.com is "80% Perl".
These are not toy corporations. These are seriously big operations, using Perl for
daily mission-critical operations, with code bases numbering in the hundreds
of thousands of lines of code.
There are 1.5 million Perl programmers, with 200 new programmers a day.
You are in good company.
-- Randal L. Schwartz, Perl hacker
| [reply] |
A reply falls below the community's threshold of quality. You may see it by logging in. |
RE: Can perl be anything like Java?
by turnstep (Parson) on Sep 20, 2000 at 00:38 UTC
|
Has anyone sucessfully walked accross the line of midsize (tens of
thousands of lines of code) application into the domain of huge business
to business corporation while keeping perl's flexibility intact?
I've seen some pretty big perl projects, but not at "tens of
thousands of lines." However, I used to code in C extensively, and
I am always aware that a perl program can do the same thing in 1/20th of
the lines of source code that another language can. Or less. And do a
better job of it. :)
Could perl be turned into a VM kind of model?
Probably not in the way that Java is, but Perl has it's own
set of strengths. As far as I am concerned, it's practically a
VM language now - I can write a perl script and run it on a
VMS, DOS, Solaris, or Linux box, and have them all run the
way I intended it, without worrying about internals like the
size of a short or how the file system works.
Will PalmPerl ever exist?
As I said in an earlier post (too busy to dig now), it is being
worked on, but has a big obstacle in that Palms (and other PDA
OSs) have a very, very small pool of memory to work with, which
we've all but taken for granted the last few years as modern
computers have memory undreamt of 10 years ago. I think it is possible,
but it will be a scaled-down version, and it will require a little more
memory than most PDA's currently have.
Will perl byte code ever be viewed as an object that exports a clean well
documented API for developers, or even automated systems to make calls
against?
Interesting question. On the one hand, it could be argued that
perl is already well documented, and you can make your code as
"strict" (PI) as you want it to be. On the other hand, the
"More Than One Way To Do It" is definitely a major strength, and I would
hate to see it go the way of VB and have to use
StrictlyDefinedReallyLongNamedFunctions
that never do exactly what you want them to. :) What would you improve
about the current state of Perl? (Meant as an honest question -
the API point is interesting)
| [reply] |
RE: Can perl be anything like Java?
by mrmick (Curate) on Sep 20, 2000 at 19:10 UTC
|
My two cents worth............
First of all, let me say that there are always people with their little 'view' of Perl. By this I mean that those who have embraced such languages as java and used Perl for only a few small tasks have no real appreciation for the power that Perl provides.
I work in a corporation of more than 80,000 employees, many of whom do programming at some level. You would probably be surprised that there is still a biased view against Perl here given that many of our critical systems include programs written in Perl. Many still think that Perl is still a 'glue' language that wouldn't be used for any serious applications. Others think of it as simply a CGI language.
My personal view is that Perl can do anything that Java can (and even better in many cases) except create a web applet. Even then, Perl can write, compile, and execute the java applet. I use Perl for most tasks because it allows me to create programs more easily and faster than with the other languages.
oh - and java is no more portable than Perl.
Mick | [reply] |
RE: Can perl be anything like Java?
by Anonymous Monk on Sep 21, 2000 at 11:50 UTC
|
Morgan Stanley Dean Witter is a huge investment bank with
offices world wide and about 60,000 employees, of which 2,000
in IT. The entire company runs on Perl. It's the number 1
language for internal development, followed by C++. They
avoid C as much as possible, and Java isn't popular either.
As one of their people recently said "What we are doing with
Perl goes beyond what Java only promises so far, and we have
been doing so for years". | [reply] |
|
Yes, MSDW is a massive Perl shop. I have interviewed there twice. Once for perm, then I turned it down. And secondly for a contract, and I turned that down. The second time I met CPAN author Brent Power (BPOWERS). He said that they were going to pay all of the 55K for Damian outright, but the Yet Another organization told them to back off.
They still have Damian scheduled to come there for 2 full weeks of lectures.
They also have their own internal "Perl monks"/comp.lang.perl.misc inside of MSDW with rapid-fire question-and-answer service.
One problem they have with Perl is CPAN. First, there are serious legal issues for MSDW in using CPAN. Second, a company with as large and critical a codebase as MSDW cannot afford to use public modules whose API can change on a whim, (e.g., the much-touted Date::Manip has changed its API 4-5 times) or where the support is limited to the email address of someone in a completely different timezone with limited ability to respond.
There is much to be said for knowing that you can call up someone between the hours of 9 and 5 and get immediate help for whatever problem you may have with the language you are using.
| [reply] |
|
Yeah, I can vouch for this because I had an interview with them. Their COMET file transfer app which provides file transfer for all of MSDW's e-business is written entirely in Perl.. with use English by the way.
| [reply] |
|
Is that a company mandate, or just an internal culture
thing? If the former, it would be the first time I had
seen something like that. Interesting. Most large corporations
worship at the altar of M$ V[B|C](++)? while knowledgable
monks quietly keep things like the mail server running
through Perl and Linux skills. :)
| [reply] |
RE: Can perl be anything like Java?
by jptxs (Curate) on Sep 20, 2000 at 02:52 UTC
|
FYI, I am currently writing an ERP-like scheduling system for my employer all in Perl. 6000++ lines of code so far. more to come after i get through the rest of the new nodes :)
-- I'm a solipsist, and so is everyone else. (think about it)
| [reply] |
RE: Can perl be anything like Java?
by zejames (Hermit) on Sep 20, 2000 at 19:52 UTC
|
Hello,
> Could perl be turned into a VM kind of model?
As far as I know, that kind of thing may be possible one day. Even thought Perl and Java 's byte code isn't the same at all: Java's is low level (near from a real CPU) whereas Perl's is high level ('print' can be a node in the byte code tree, for example). In fact, I heard that Malcom Beattie was about doing that in his Perl compiler, and that would provide what you want.
However, this may not be done before a long time ... And moreover it is not sure that it will be really interesting: the Perl compiling time may be equivalent to the byte code loading time, and then what Perl does is the same: interpreting!! So I'm not sure Perl VM is going to be really efficient :-((
James
| [reply] |
RE: Can perl be anything like Java?
by d_i_r_t_y (Monk) on Sep 21, 2000 at 09:41 UTC
|
Has anyone sucessfully walked
accross the line of midsize (tens of thousands of lines of code) application into the domain of huge business to
business corporation while keeping perl's flexibility intact?
well... i'm presently up to around 30,000 lines of perl for
a bioinformatics website i am working on. as is my fashion,
it is heavily object-oriented and this has paid off signficantly
in managing the way the project has grown in response to
my personal whims and user requests.
while i do not pretend to be any kind of 133t perl haXor,
i would say that the most difficult/frustrating thing about
perl and perl OO is the lack of strong typing and possibly
the lack of a full-featured, typed exception system, such
as in java. it is simply
too onerous to write code to catch every bug and/or foreseeable
misuse of a given method or object -- especially when
large and complex objects are extending
and using other objects. i'm not saying it's impossible by
any means -- just much more difficult than java because of
the strong typing plus the compiler.
call it heresy if you will, but i sure wish perl had strong
typing (and method prototypes)... loaded via a compile-time
pragma... without adversely affecting execution speed...
it is very difficult indeed to have 30,000+ lines
of accurately-documented OO perl code. but i am trying
very hard to make it so. freeform text marked up as pod
embedded in code sure has its place, but there is no
comparison in perl for the javadoc utility, which again
is made possible through java's (obsession with) typing and
objects.
it seems very likely that OOP in perl6 will be more-or-less
made a part off the core language (if you want it), instead
of being tacked 'on-the-side'. hopefully there will also
be some more OO 'syntactic sugar' keywords like 'class',
'extends', 'method', 'private', 'this' etc.. - even if these are just aliases
to the more familiar 'package', '@ISA', 'sub', 'my', 'my $this = shift;' etc.
it would give me a nice warm feeling to be able to write...
use very_strict;
class PerlModule extends SomeModule
{
our $Class_Data;
method set_something ( int $something )
{
this->_update_something( $something );
this->something = $something;
}
private method _update_something ( int $raw_something )
{
# ...
}
}
...in perl. the lack of prototypes and typing in perl is
the only reason i even know java.
j.a.dirty.p.h.
| [reply] [d/l] |
|
| [reply] |
|
...and we are both australian... i wonder what that means? ;-)
indeed, i had seen Class::Contract, and while in the desired
direction, syntactically, it's a little ugly and deviates
too much from my colleague's styles for me to force them
to submit to the same style when they use some of my code.
i don't think i'll be completely satisfied until we see what
comes of the RFC's for perl6. the repeated calls for more
and tighter OO support is sure encouraging... combine this with an OOP-tailored enhanced version of pod
a la javadoc for the ultimate in perl API auto-documentation and the world is ours.
it would be a massive victory for the Perl way if one will
be able to code OOP in perl as strictly as java (ie with strong
typing, exceptions and so forth) with the simple addition
of some object pragma -- and then to turn around and write
a 10 line text filter to clean up some windows-turkey's excel
spreadsheet....... ;-)
thanks for the reply,
j.a.dirty.p.h
| [reply] |
RE: Can perl be anything like Java?
by princepawn (Parson) on Sep 20, 2000 at 23:43 UTC
|
I think a simpler question or observation about Perl is in order. It is a much more complicated language than Java. It may in fact be more powerful, but it also much more difficult to understand. E.g., take the local() function in Perl. Or the "Gory details of parsing quoted constructs" in the perlop manpage. It may take more lines of core language to do things in Java, but it doesn't take as much education (or line-noise-looking syntax) to do it.
It is also safe to say that the strength of Java lies mainly in its libraries, whereas considerably more strength is available in the much larger and context-sensitive Perl core language. You can learn all there is about the core Java language in a much shorter period of time than Perl. Learning Perl is closer to learning English: I may be native, but I didn't know what solipism was until a moment ago.
Finally, I will never forget what one prospective employer said to me: "It is much harder to find a good Perl programmer than a good Java programmer."
| [reply] |
Re: Can perl be anything like Java?
by KM (Priest) on Nov 28, 2000 at 20:54 UTC
|
My question, is can perl support a huge corporation?
One of the companies I used to work for was a third party warehousing and distribution company. Some of the customers are
folks like Sun, Goodyear, Wal-Mart, and some hefty pharmacutical companies, to name a few.
You may say, "so what?" Well, what I worked on was (mostly) the backend system, which made sure that the warehouses
knew what stores needed what, and when. So, everything you see on the shelves at a Wal-Mart is there because
Perl told the warehouse to get it there, and Perl told the main system that things were packed and shipped. Perl also
let the companies know what their inventory was (via a web-interface) in any given warehouse, and allowed them to
shift inventory.
So, not only can Perl support a huge corporation, but it also supports many of the goods you see on the
shelves at various stores, as well as making sure hospitals and pharmacies have their needed drugs.
Next time you go into your local Wal-Mart (which I boycott, but that is another story) or K-Mart (too bad it isn't KM-art),
you can thank Perl that the item you want is there, and in stock. If you are a customer of Sun,
and call them saying you need a new monitor in an hour, and it gets to you in an hour.. thank Perl. If you need
emergency surgery which required something like the drug Botox, thank Perl (and me, since I wrote all the software that
that warehouse uses).
Perl is everywhere.. lurking, working, and making things work.
Cheers,
KM | [reply] |
|
Your post is stimulating for a few reasons.
One, though not mentioned, your Perl products must have used extensive logging and transaction control, in addition to secure file transfers.
Second, the big problem with Perl in my opinion are the types of texts published about it. There are reams of books on the Perl language but very few about Perl as the language for architecting complex systems.
In contrast, look at the catalog for Addison-Wesley, for example. There are books there on Java regarding Business Logic, Intelligent Agents, Design Patterns, Full E-Commerce Solutions. In other words, many of books on the subjects that grab the attention of CIOs and CEOs of major corporations.
In my opinion, KM, you need to do more than tell us about how this is done. You need to write a concrete text showing HOW it is done and WHY Perl is best-suited for the job. For, if we had to do something of this scale and robustness, most of us we would be lost.
| [reply] |
|
One, though not mentioned, your Perl products must have used extensive logging and transaction control, in addition
to secure file transfers.
Oh yeah. Everything was logged, replicated, backed up, etc... There were two DBs used, Informix and MySQL.. both backed up daily, and
using transactions (we did some hacking to replicate transactions in MySQL in various ways). Any files
which were transfered anywhere were encrypted and digitally signed.
Second, the big problem with Perl in my opinion are the types of texts published about it. There are reams of books on
the Perl language but very few about Perl as the language for architecting complex systems.
Well, in the book I just finished this is somewhat taken care of, in a roundabout way. It is about writing CGI apps with Perl.
In the book, many things are shown, which as a whole should give the reader an idea of how to use the various Perl tools to write applications.
Although the book is geared to CGI, the concepts are the same.
One of the problems I see, is that people (CIOs, et al) may not think Perl can do what it can do, so they use a buzzword compliant language.
Hopefully, they use the Right Tool for the job. If that is C, so be it. If it is Java, then so it is.
I don't know that books on architecting complex systems with Perl would make people do it. First, you need to know how to
architect a complex system, then choose the tool(s) to make it a reality.
Another project we worked on was a portal between vendors. The central server for this was
done in Java, and the grunt work with Perl. Many robust systems use different tools to accomplish what the blueprint lays out.
You need to write a concrete text showing
HOW it is done and WHY Perl is best-suited for the job.
Do I? How would I show you how it is done (I can't show you the code)? Nothing magical was done, heavy DBI usage, cron jobs,
CGI, some Win32 Perl, etc... Nothing that hasn't been explained a billion times already. Most of the it was on one side you have a
FourGen interface into Informix, scripts that move data from Informix to MySQL, a web front end to MySQL, and scripts that move data
from MySQL to Informix. Perl handled all EDI transactions, putting them into Informix, which replicated to MySQL, etc...Not brain surgery.. just timing and
having a decent blueprint to create the system around (many flow charts, specs, test cases, and more flow charts).
For, if we had to do something of this scale and robustness,
most of us we would be lost.
Why would people fail? The only reason I could think of is not knowing what Perl can do, or not knowing how to do it.
That is the fault of the individual, not on the size of the system. I mean really, many systems today are "Put crap in a DB, take crap out of a DB".
Figuring out what to do with the crap, validate the crap, munge the crap, display the crap, etc... are the details
architects and developers need to figure out. That is the hard part.. writing it in Perl is the easy part.
Cheers,
KM
| [reply] |
Re: Can perl be anything like Java?
by Dominus (Parson) on Nov 28, 2000 at 21:37 UTC
|
Says pos:
> My question, is can perl support a huge corporation?
Folks at Morgan Stanley Dean Witter tell me that if
for some reason Perl stopped working one day, their entire
company would be out of business in three days. More
than one person there has told me this. They apparently
see nothing wrong with letting Perl support their
corporation.
<joke>But perhaps Morgan Stanley Dean Witter isn't
huge enough to qualify here. AFter all, ther are
nearly thirty other corporations that are huger.</joke>
| [reply] |
|
I love hearing about perl success stories, however corporations that don't focus on object reusability, centralized management, and the available talent pool, do so at great risk to long term objectives.
MSDW made a corporate commitment to Perl when java was still a fat ugly child that hogged more resources than produced results. They were in a position to make perl work for them. But the great bulk of the brick and mortar world is approaching the Open System and Open Source world with the cynisism of the mainframe mindset, relying upon much longer historical perspectives than most Open Source folk care to respect.
During the course of evaluating app servers I pointed out that it seemed foolish to purchase such expensive solutions when Open Source alternatives like Jonas or the Jonas/Enhydra solution were available open source, and that the code was actually cleaner than it's commercial counterparts. It was instantly shot down with the famous line "Who's going to provide 24x7x365 instantaneous production support". I pointed out that with the money that would have gone to licensing and services the corp could provide it's own support staff. This was promptly shot down with issues of available talent, Human Resource issues, and of course the inevitable legal Intellectual Property problems.
Morgan Stanley may be able to afford the requirements for supporting perl and open source, but most managers find that a 1-800-xxx-xxxx number easier to explain to the top brass than the myriad of complexities that surround the support of Open Source.
coreolyn Duct tape devotee. -- That's OO perl, NOT uh-oh perl !-)
| [reply] |
Re: Can perl be anything like Java?
by coreolyn (Parson) on Nov 28, 2000 at 20:25 UTC
|
I know I'm responding to an old node, but as I went through the site trying to catch up on everything I've missed (having been forced into evaluation java applicaton server solutions) I just had to put in my two cents.
As usual I feel stuck in between corporate requirements and a language that appeals to my personal sense of creation. Understanding the needs of one and the limitations of the other is a very frustrating position.
Java has become the wave in large established corporations for one reason - J2EE standards (and a frontal media/sales assault). J2EE gives large corporations the ability to tie together large disperate data sources, via CORBA, DCOM, RMI, in a way that hundreds of developers can work on simultaneously and cooperatively, all the while establishing a common API accross the enterprise.
If perl desires a piece of that market it needs to be able to construct stubs and wrappers that allow perl OO code to wrap into the J2EE standard (or even better wrap the J2EE standards into it!). But perl is a language of creativity and straight line to the point solutions, As such, it will always be a leading language in flexibility, and innovation. Perl is the ice cutter for where java wishes it could go.
After evaluating eight of the leading application servers I'm totally under-impressed. These are all poorly maintained works in progress with a big price tag and a hundred heavyweight acronymns for nothing more than a J2EE enabled web server. Java is not better than perl, but it is easier to manange and scale, therefore, the management of large organization can only seriously consider Java solutions at this time.
coreolyn Duct tape devotee. -- That's OO perl, NOT uh-oh perl !-)
| [reply] |
|
I have to agree with you here. I am working at a digital music company now. They are using
Broadvision as their application server to an informix database backend.
There are probably 60 people working on this project and you are right, it is amazing how easily the work is distributed among different task forces here.We have content developers, database administrators, system performance evaluators, user assurance (QA) testers, and of course, flat file parser/generator Perl people like me.
The competitor app-server for Java is called
Dynamo by Art Technology Group. One of its strong points is how it automatically profiles user browsing activity to allow people to get ideas of user system use.
| [reply] |
|
|