amateur perl questions

--===============2050349790==
Content-Type: multipart/alternative; boundary="0-566155159-1174391360=:60199"
Content-Transfer-Encoding: 7bit

--0-566155159-1174391360=:60199
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Bill/Brian et al.
=20
I have a few queries coming to my mind ... though not technical enough;=
but surely any light anybody can through on this would silence the quest=
ions in my head.
=20
1. Is there a internationally-recognised Perl-Certification Exam offere=
d by ActiveState??
2. I have seen the OOP concepts of Perl, but they dont look convincing =
as Java/C++ OOP.
Do u really think Perl can be labelled as an OO-language??
=20
Apologies if these questions sound amateur.
=20
Best,
Ukh

=20
---------------------------------
Get your own web address.
Have a HUGE year through Yahoo! Small Business.
--0-566155159-1174391360=:60199
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

RE: amateur perl questions

This is a multi-part message in MIME format.

--===============0463228231==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C76AFF.346877DD"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C76AFF.346877DD
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Ukhas,
=20
Every now and then someone asks about certification, but the general
consensus in the Perl community is that certification is not
particularly useful.
=20
As for OOP, Perl is very OO. It has built-in support for data
hiding, encapsulation, method calls, the whole ball of wax. Plus it has
powerful reflection, run-time definition, and exception-handling
capabilities. It is every bit as capable an OO language as Java or C++
or C#; just different. I personally have programmed in all three, and I
greatly prefer Perl's OO model.
=20

Eric


________________________________

From: activeperl-bounces@listserv.ActiveState.com
[mailto:activeperl-bounces@listserv.ActiveState.com] On Behalf Of ukhas
jean
Sent: Tuesday, March 20, 2007 7:49 AM
To: Active Perl
Subject: amateur perl questions


Hi Bill/Brian et al.
=20
I have a few queries coming to my mind ... though not technical enough;
but surely any light anybody can through on this would silence the
questions in my head.
=20
1. Is there a internationally-recognised Perl-Certification Exam offered
by ActiveState??
2. I have seen the OOP concepts of Perl, but they dont look convincing
as Java/C++ OOP.
Do u really think Perl can be labelled as an OO-language??
=20
Apologies if these questions sound amateur.
=20
Best,
Ukh

________________________________

Get your own web address.
n
s/?p=3DBESTDEAL>=20
Have a HUGE year through Yahoo! Small Business.
n
s/?p=3DBESTDEAL>=20

------_=_NextPart_001_01C76AFF.346877DD
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable



charset=3Dus-ascii">

Eric

RE: amateur perl questions

From: activeperl-bounces@listserv.ActiveState.com
[mailto:activeperl-bounces@listserv.ActiveState.com] On Behalf Of ukhas
jean
Sent: 20 March 2007 11:49
To: Active Perl
Subject: amateur perl questions

> Hi Bill/Brian et al.
> =

> I have a few queries coming to my mind ... though not technical
enough; but surely any light anybody can =

> through on this would silence the questions in my head.
> =

> 1. Is there a internationally-recognised Perl-Certification Exam
offered by ActiveState??

I am not aware of any internationally recognised Perl certification
offered by anybody. Brainbench used to provide assessment tests, and
probably still do, for a fee. There are possibly other similar
commercial organisations. Personally, I tend to agree with the
sentiments expressed here
http://www.oreillynet.com/onlamp/blog/2004/01/perl_certifica tions_are_a_
hot.html. However, silencing the questions in your head may require
medication :-)

> 2. I have seen the OOP concepts of Perl, but they dont look convincing
as Java/C++ OOP.

Depends on your point of view. There are plenty of people who are not
convinced by Java or C++ OO capabilities.

> Do u really think Perl can be labelled as an OO-language??

(Assuming s/u/you/) Personally no, I wouldn't call Perl an OO language,
as I think that that term should be reserved for languages that only
permit OO, e.g. Smalltalk. I would say that Perl (as well as C++ and
Java) supports OO, as it supports other programming/design paradigms,
and supports it quite well enough. I expect that Perl 6 will have better
OO support.

> =

> Apologies if these questions sound amateur.

I am sure I heard somebody say once that "There is no such thing as a
stupid question, but plenty of stupid answers".

HTH

-- =

Brian Raven =


==================== =====3D=
================
Atos Euronext Market Solutions Disclaimer
==================== =====3D=
================

The information contained in this e-mail is confidential and solely for the=
intended addressee(s). Unauthorised reproduction, disclosure, modification=
, and/or distribution of this email may be unlawful.
If you have received this email in error, please notify the sender immediat=
ely and delete it from your system. The views expressed in this message do =
not necessarily reflect those of Atos Euronext Market Solutions.

Atos Euronext Market Solutions Limited - Registered in England & Wales with=
registration no. 3962327. Registered office address at 25 Bank Street Lon=
don E14 5NQ United Kingdom. =

Atos Euronext Market Solutions SAS - Registered in France with registration=
no. 425 100 294. Registered office address at 6/8 Boulevard Haussmann 750=
09 Paris France.

L'information contenue dans cet e-mail est confidentielle et uniquement des=
tinee a la (aux) personnes a laquelle (auxquelle(s)) elle est adressee. Tou=
te copie, publication ou diffusion de cet email est interdite. Si cet e-mai=
l vous parvient par erreur, nous vous prions de bien vouloir prevenir l'exp=
editeur immediatement et d'effacer le e-mail et annexes jointes de votre sy=
steme. Le contenu de ce message electronique ne represente pas necessaireme=
nt la position ou le point de vue d'Atos Euronext Market Solutions.
Atos Euronext Market Solutions Limited Soci=E9t=E9 de droit anglais, enregi=
str=E9e au Royaume Uni sous le num=E9ro 3962327, dont le si=E8ge social se =
situe 25 Bank Street E14 5NQ Londres Royaume Uni.

Atos Euronext Market Solutions SAS, soci=E9t=E9 par actions simplifi=E9e, e=
nregistr=E9 au registre dui commerce et des soci=E9t=E9s sous le num=E9ro 4=
25 100 294 RCS Paris et dont le si=E8ge social se situe 6/8 Boulevard Hauss=
mann 75009 Paris France.
==================== =====3D=
================

_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

Re: amateur perl questions

The OOP ones are ... well. Not sure what you want here - perl does OOP
(one of the best books out there is D. Conway's "Object Oriented Perl"
(Manning)) as well as you want it, as long as you recognize Larry bias
that enforced encapsulation (by the language) is wrong - a paraphrase of
his reasoning is "People should stay out of your living room w/o being
asked because it the right thing to do, not because you have a shot gun."
There are a couple tricks to make perl more and more unbreakably OOP
(inside out objects, for one) but the general feeling is its not worth the
effort. OOP should be enforced by ease of use - if somebody needs to pick
around on the inside of your object, you've got a programming issue, not a
language issue.

OOp isn't ... you know, like an IEEE standard or something, it a
methodology. Perl lets you do the method (lots and lots of magic object
building modules) but isn't going to force you.

a

Andy Bach
Systems Mangler
Internet: andy_bach@wiwb.uscourts.gov
VOICE: (608) 261-5738 FAX 264-5932

"Cacoepy" is not to be confused with cacology "bad choice of words." The
antonym of "cacoepy"
is orthoepy "the correct pronunciation of words." "Cacoepistic" is the
adjective form of today's word
and a person who often mispronounces words is a "cacoepist."
http://www.yourdictionary.com/wotd/wotd.pl?word=cacoepy
_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

Re: amateur perl questions

Hi Eric Et al.
I've only been using PErl for a couple of years and am not totally sold on =

OOP yet, either. I'd like to address Some of the points you raised, though, =

from a different angle. I've been thinking of Perl OOP for some time and =

thought bringing up some of this criticism in comp.lang.perl.misc. But =

frankly speaking, I havent' dared because of the pretty strict culture =

against newbie:ish posts in there. I just feel like I might not be ready to =

defend my stance in the big arena. But now that this came up in a =

low-ttraffic list, here we go:

Roode, Eric wrote:

> As for OOP, Perl is very OO. It has built-in support for data
> hiding, encapsulation, method calls, the whole ball of wax. Plus it
> has powerful reflection, run-time definition, and exception-handling
> capabilities. It is every bit as capable an OO language as Java or
> C++ or C#; just different.
Just different is the key to me. When initially trying to learn the Perl OO =

basics after Java and C++, I thought what a hack, I mean who wants to use =

such a thing. But after having abandoned it and coded some more, getting =

accustomed to the Perl culture and way of thinking I returned to it. I made =

an observation that in larger scripts I would write functions that =

manufactured, ate, mangled and processed references to hashes as their firs=
t =

argument. THen I happened to revisit Perl OOP first in beginning Perl which =

explains it well, then in the Camel book and finally in the official docs. =

At some point things just clicked. Perl OOp is a lot about passing in =

references to hashes as instance data, with syntactic sugar and inheritance.

Now while I am not wild about Perl OO still, I can appreciate and understan=
d =

the design to a certain extent, as a minimalist way to retrofit OO on top o=
f =

the current design while keeping Perl Perl. and trying to make up creative =

uses for the more exentric and dynamic ffeatures fills me with delight. I =

find that when comparing Perl to most other OOpy langs, I often start my =

sentence with "But in Perl you can ..." I did that just today when a Unix =

friend of mine rantedd about how bad PHP OOP can be at times.

Anyway the problem with perl OO as I see it, is not that the language would =

not be up to it, but how alienated OO seems to be from the average Perl =

module. I don't mind the purely procedural modules, in fact I like most of =

them, but the average OO module seems to be just a bunch of functions for =

working with one or two kinds of blessed hash. I mean, it really, quite =

often, is not much more OOpy than a good C library. The fact that you can =

ducktype, i.e. call similarly named methods regardless of inheritance, is =

often very powerful but it also does mean that more often than not there's =

no real official interface specification at all, even in modules that would =

benefit from one. That in turn means that reuse of modules is not that high=
, =

though I've seen quite many that piggyback on various Internet clients.

Another trend is shyness about abstraction. It's funny I should mention thi=
s =

as I switched from Java to Perl to avoid abstraction when it felt especiall=
y =

daunting in small scriptlets. Anyway, where libs for other langs would let =

you inherit from a class or plug in an interface implementation, many Perl =

modules are quite happy with a sub-routine reference. IT would be OK if tha=
t =

was a wrapper for some OOPy concept but your average coder will false-lazil=
y =

try too a procedural solution first, when tempted. At least I tend to do =

that, . Compare this to Java's system of listenre classes or C#, in =

which even a basic window requires that you inherit from a well-defined =

class. There's WX Perl, of course, but even in its intro in www.perl.com th=
e =

author said that he found it uncanily oopy and somewhat Unperlish, or =

something to that effect, which is quite teling.

While I do think Java is often overkill in this regard, and often am happy =

about Perl's straightforward take on things, many many modules could do wit=
h =

more abstraction. Take the modules in the MIDI namespace, for instance. THe=
y =

offer you, nothing more abstract and grander, than a plain reference to an =

array whose structure varies from one module to the next in the set. =

Contrast that to the variety of classes, nicely named accessor methods and =

such that you get in the java standard classes for MIDI. Sure that's =

abstract as heck and could be documented better, but still. They aren't tie=
d =

to the underlying data format, either, though I'm sure that won't change fo=
r =

a while. MIDi has been round for 20 years or so and I've tinkered with it =

for the last 10 mostly recreationally through a sequencer.

Another problem is that there are no standard ways to iterate over things =

apart from foreach and tied handles. I'm not sure if OOPy interfaces in the =

core modules would solve this but there's an amazing variety of slightly =

incompatible iterators and implementations of map, grep et al using them. =

This is at least a tentative notion I have after having read most of =

HIgher-Order Perl and taken a look at various modules for more specialized =

data. In contrast, the iterator interfaces in C++ STL or Java are nowadays =

well established, though I recall the time when that was not the case for =

Java.

Lastly howabout error handling. That's something that surely needs =

improvement. I've seen many procedural and OOPy modules whose author's don'=
t =

bother to use or at least explain errno values against which you could matc=
h =

and take different actions to recover gracefully and as smartly as possible=
, =

from the user point of view. EQuallly many are classes with string-based =

exceptions that go undocumented. While I'm a big fan of the x or die "canot =

x due to $^E" style, it doesn't always do in large programs or GUis. There =

is the ability to make exception classes with specific info and sensible =

names, but how many modules do use them and is there again anything like a =

defacto standard base class for them? Looking at docs for modules, there =

are two things that caught my eye. While not deadly at all, they certainly =

discourage OOP and you feel like having to invent hacks to stay OOPy. This =

is Perl 5.8.7.

Quote perldoc carp:
Bugs
The Carp routines don't handle exception objects currently.
End quote.

quote perldoc -f die:
Although this feature was to be run only right before your program was to =

exit, this is not currently the case--the $SIG{__DIE__} hook is currently =

called even inside eval()ed blocks/strings! If one wants the hook to do
nothing in such situations
End quote.

Oh and before I forget, I've been looking into Ruby. THe author said in a =

book basically that he made Ruby easy, elegant and high-level for people to =

create elegant programs that are smart and polite. That's in stark contrast =

to the PErl culture and your average Unix app which might blurt out things =

like cannot stat x". I wonder if this is, in fact the culture in Ruby codin=
g =

in general, or if the convenience is also greatly employed to quickly =

compose quick-n-dirty programs for small jobs. Tiny apps I call scripts are=
, =

in fact, an important feature and one of the reasons why I like Perl, but =

the mentality can be a problem in large software, including habits you'l =

have to unlearn.

Finally, I'd love to hear what you people do like about PErl OO and if ther=
e =

are any good solutions for the issues I've raised apart from waiting for =

Perl 6.

-- =

With kind regards Veli-Pekka Tätilä (vtatila@mail.student.oulu.fi)
Accessibility, game music, synthesizers and programming:
http://www.student.oulu.fi/~vtatila/ =


_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs