[sf-perl] Real perl

[Dodger]

Yup yup! That trade-off is also part of why I enjoy building my own abstraction layers. I can keep them slick and only doing what I need, expanding them if need be, and make them work for the way I think. And I can optimise them for their tasks. 

Not to mention that sometimes abstraction layers fail not only in not doing what they are supposed to, but in abstraction itself. 

An example of this outside of Perl I could make is an XHR with a callback function compared between a direct JavaScript XHR construction and using the prototype library.

 Me, I will happily do the stuff manually. Since I've already got a "getUA" function to handle the "IE walks its own stupid path" problem with setting up the XHR object in the first place, it only requires one more line of code than the Prototype.Ajax object--the one where I check if the state is "4"--and it's not prone to dying if some other library is used at the same time. But mostly because with the rest of the stuff I'd have to declare, it can actually take more code to use Prototype. 

The other way they can fail is by simy not being abstracted in a way that suits me. Using that same example, and having coded in Perl for 17 years, I'm used to the LWP approach, and an appropriate XHR abstraction for me would take this into account and try to act similarly. Someone used to the PHP curl interface however might want a whole different way of doing things. 

Again, I have no beef with Moose. If it gets the job done for other people more power to them. But I actually think perlishly and to me Moose is not very perly and so doesn't help me. 

I was just interested in starting some conversation on something that isn't Moose because all I seem to see on lists anymore is Moose this and Moose that. 

It's like trying to find a discussion on Ruby. Without Rails. 

-- 
Dodger

Sent from my iPhone

On 11/04/2012, at 11:39 AM, Paul Makepeace <Paul.Makepeace at realprogrammers.com> wrote:

> On Wed, Apr 11, 2012 at 03:33, Dodger <el.dodgero at gmail.com> wrote:
>> I might also actually like knowing intrinsically how what I have made works.
> 
> Writing software is a discipline where there's a level of abstraction
> where everything just goes black (box). It might be at "CPAN modules"
> it might be at "Perl source code" it might be at "libc implementation"
> it might be at "kernel scheduler" it might be at "filesystem device
> driver" it might be at "L2 cache microcode" and so on down to particle
> physics. At some point you stop caring and just trust it works.
> 
> IMO generally the higher level that is the more you can get done, and
> those times when trust breaks down (i.e. an abstraction isn't
> fulfilling its published contract) are the relatively fewer times you
> ever have to care what's beneath the black.
> 
> That said, nothing wrong with liking knowing, it's just probably not
> going to get as much made in the long run :)
> 
> Paul