Why perl lost steam...
Bill Stephenson
No more. Now it is practically dead.
It would seem that right now, when "Web Apps" are really coming into
their own, CGI scripts written in Perl would be the place that
"Beginners" would start looking.
But there are no beginners here anymore.
Why is that?
Eko Budiharto
not exactly this mailing list will be dead. It is probably passive for
this moment. It is impossible perl will loose from the IT world. If
there is no beginners, it is good, right? Because there will be more
expert people can help beginners/newbies. :)
zach
'a beginner', and i guess this type of person will directly choose a framework
for
completing the work, perhaps 'the newbies will be found at other mailing lists
(C:: A or Mojolicious Catalyst) ?
Zak,
http://perl-zacko.blogspot.com
----- Pesan Asli ----
Dari: Bill Stephenson <bi...@ezinvoice.com>
Kepada: beginners cgI <beginn...@perl.org>
Terkirim: Sel, 21 September, 2010 03:39:32
Judul: Why perl lost steam...
Why is that?
-- To unsubscribe, e-mail: beginners-cg...@perl.org
For additional commands, e-mail: beginners...@perl.org
http://learn.perl.org/
Ask Bjørn Hansen
> This email list used to bustle. It was active and vibrant.
>
> No more. Now it is practically dead.
Looking at job statistics and activity in all the "web related" Perl
projects I think it's more a matter of this list being spectacularly
badly named.
- ask
David Taiaroa
Interesting question. I find that now I often use PHP and CMS options like
Joomla to handle tasks that 10 years ago I would have turned to Perl to
solve.
Panchroma Website Development
Moncton :: Riverview :: Dieppe
Eko Budiharto
it is true many people are using CMS more often and I think all CMS are
using PHP instead of perl. But for me, I am using any kinds that can
help me to achieve my goal, not restricted to one technology.
I am still using perl for my backend. :)
On 9/21/2010 9:46 AM, David Taiaroa wrote:
> Hi Bill, Eko,
> e
Tiberiy Virtgaym
Where do i begin to learn Perl CGI?
Thank you.
Tiberiy Virtgaym
Operational Excellence, LS2 Support
Deutsche Bank
2 Harbor Side NJ Jersey City 07311
201-593-2355
------------------------------------------------------------------------------------------------------------------
This mail is transmitted to you on behalf of HCL Technologies.
Diese Post wird Ihnen im Namen der HCL Technologies ubermittelt-
------------------------------------------------------------------------------------------------------------------
Eko Budiharto <eko.bu...@gmail.com>
09/20/2010 09:50 PM
To
Bill Stephenson <bi...@ezinvoice.com>
cc
beginners cgI <beginn...@perl.org>
Subject
Re: Why perl lost steam...
--
To unsubscribe, e-mail: beginners-cg...@perl.org
For additional commands, e-mail: beginners...@perl.org
http://learn.perl.org/
---
This communication may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this communication
in error) please notify the sender immediately and destroy this
communication. Any unauthorized copying, disclosure or distribution of the
material in this communication is strictly forbidden.
Deutsche Bank does not render legal or tax advice, and the information
contained in this communication should not be regarded as such.
(Randal L. Schwartz)
Eko> it is true many people are using CMS more often and I think all CMS
Eko> are using PHP instead of perl.
You are mistaken.
PHP is only one of many viable options for CMS. Perl is another. So
are Ruby and Python and [insert any modern language here].
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<mer...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
Dermot Paikkos
[DP] The perl beginners list is still very active and I think that's
where all the traffic tends to be. If you were writing a "Web App"
though, you would be better served by a perl framework like Catalyst or
CGI::Application. Personally I only use CGI for smaller tasks.
Dp.
Robert Roggenbuck
it depends how much You know about CGI in general. If you already know the
basics about HTML-programming and the principles of CGI just have a look in the
very detailed documentation of the Perl CGI module
(http://search.cpan.org/~lds/CGI.pm-3.49/lib/CGI.pm).
If HTML and CGI are new for You have a look into the good tutorials at the "Web
developers Virtual Library" (with the disadvantage of a lot of advertisements)
(http://www.wdvl.com/Authoring/CGI/) or e.g. at the tutorials at w3schools
(http://www.w3schools.com/).
Hope that helps
Robert
--
Bill Stephenson
> Your preference to hark back to perhaps obsolete software strongly
> suggests your need to rethink the bases of your decision-making ideas.
Probably. Or just get out of the game entirely.
But hear me out because this post contains some beginner's questions...
I've been working on an iDevice web app lately. It's a small, focused,
app. I made it with CGI.pm, no other perl modules, and the Prototype JS
libraries.
This little app uses the CGI->save method to store user preferences on
the server. Now, since the file the preferences are stored in is named
the same as the user's username the app knows right where to find it,
and CGI.pm loads their data into an object pretty darn quickly. This
probably is easier to code, and probably requires less processing power
than using any SQL database engine for apps that have a user base of up
to 100k users, maybe even more.
I am wrong about that?
Which is faster and/or more efficient, this:
sub get_prefs {
if (-e "./users/$user") {
open(my $FILE, "./users/$user);
$PREFS = new CGI($FILE);
close $FILE;
}
else {&error_page("Opps...")}
}
or however you'd do the same with MySQL?
I really don't understand how loading that data into a CGI.pm object
could be done more efficiently by firing up a database engine or even
making a query to one that's sitting there running all the time. That
has to require more of something, doesn't it?
My interest in peeking at Boulder was really OT, but let me explain a
little more about why it intrigues me. It seems to offer some simple
ways to search for data in sets of simple data files like those created
when using the CGI->save method, almost an SQL like way of retrieving
data from this format. And HTML5 supports a client side data storage
function that uses the same format, so the two should be easily shared
and synced between the client and server. And it may be worth looking
into how the functionality of Boulder might be recreated with JS for
the client side.
I would offer that there is a difference between something being
obsolete and being ignored. Certainly when Mr. Stein created "Boulder"
he was aware that MySQL existed. What was his motivation? Is Boulder
still being used to suit those purposes and more? If so, it's not
really obsolete is it?
And I am certainly not arguing that CGI::App and other Frameworks are
not appropriate for small apps, what I am thinking is there may be a
good reason for a simpler, ultralight, framework for small apps to
exist.
I suppose most of the functionality of that framework I imagine already
resides in CGI.pm. I just don't think it's been integrated into an
approach that's easy for beginners to excited about.
For me, creating my first "iPhone" web app has been a fun and exciting
experience and I see an opportunity for perl, as a language and the
community as a whole, to benefit from the momentum of mobile apps. Read
what Jann Linder wrote in his blog about his experience creating his
first native iPhone app:
iPhone Programming Hell :: http://www.jann.com/
Compared to Jann, and everyone that's responded here, I am, and always
will be, just a perl beginner. But my app did not require native iOS
code or a SQL database engine, so were my decision making ideas for my
approach really flawed?
I'll readily admit that some of my code may have flaws, but I need to
understand more about why my approach is before I rethink it.
Thanks to all that have responded,
Bill
Dermot Paikkos
> My interest in peeking at Boulder was really OT, but let me explain a
> little more about why it intrigues me. It seems to offer some simple
> ways to search for data in sets of simple data files like those
created
> when using the CGI->save method, almost an SQL like way of retrieving
> data from this format. And HTML5 supports a client side data storage
> function that uses the same format, so the two should be easily shared
> and synced between the client and server. And it may be worth looking
> into how the functionality of Boulder might be recreated with JS for
> the client side.
>
> I would offer that there is a difference between something being
> obsolete and being ignored. Certainly when Mr. Stein created "Boulder"
> he was aware that MySQL existed. What was his motivation? Is Boulder
> still being used to suit those purposes and more? If so, it's not
> really obsolete is it?
[DP] I can't comment on Boulder as I have never used it. I am a big fan
of SQLite because it has a small foot-print, it lightening fast and very
portable.
> And I am certainly not arguing that CGI::App and other Frameworks are
> not appropriate for small apps, what I am thinking is there may be a
> good reason for a simpler, ultralight, framework for small apps to
> exist.
>
> I suppose most of the functionality of that framework I imagine
already
> resides in CGI.pm. I just don't think it's been integrated into an
> approach that's easy for beginners to excited about.
[DP] I would say you are using CGI very appropriately, for a small,
self-contained app.
Dp.