Re: RFC: mod_perl advocacy project resurrection (and a proposal!)
I would agree. If you want to see design patterns in practical action with relation to mod_perl.. go to http://www.extropia.com/ExtropiaObjects/ and skim through Chapters 10 (App Architecture) and on (on the individual app toolkit components). Each one contains a sidebar on how design patterns affected the design of our application toolkit for CGI and mod_perl. Later, Gunther At 08:33 AM 12/7/00 -0800, brian moseley wrote: >On 7 Dec 2000, David Hodgkinson wrote: > > > Development are two of the bibles. I have to say though, > > I've avoided the Design Patterns type books purely > > because of the C++/Java bias. > >you sure are missing out. > > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Web Technology Company http://www.extropia.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection (and a proposal!)
On Thu, 07 Dec 2000 11:33, you wrote: > On 7 Dec 2000, David Hodgkinson wrote: > > Development are two of the bibles. I have to say though, > > I've avoided the Design Patterns type books purely > > because of the C++/Java bias. > > you sure are missing out. I second that. You should lose your anti-engineering bias just because of your anti-Java/C++ bias. Design patterns have nothing whatsoever to do with Java and C++, and if you ignore them, you ignore solutions to problems that plague every developer. Design patterns are fundamental to everything we do, even if we don't know it. That's not to say that they will somehow solve all your problems, but a responsible developer should learn about as many problem-solving techniques as possible. Ok, I'll get off my soapbox now. :-) Kyle -- [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection (and a proposal!)
On 7 Dec 2000, David Hodgkinson wrote: > Development are two of the bibles. I have to say though, > I've avoided the Design Patterns type books purely > because of the C++/Java bias. you sure are missing out. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection (and a proposal!)
Robin Berjon <[EMAIL PROTECTED]> writes: > At 14:07 06/12/2000 -0500, kyle dawkins wrote: > >Ok, you're missing my point but that's partially my fault for not explaining. > > First, let me agree: Java's "everything is an object" mentality sucks > >balls. And yes, Perl's duality of functional/OO is really nice. Taking that > >away is not what I am advocating... I think there should be the *option* in > >Perl to disable certain features that make Perl a dangerous language for OO > >development. First and foremost, the lack of true encapsulation is > >disastrous. There is no concept of private data because instance data is > >stored in a blessed hash (typically) that's open wide to the world. It makes > >it tough to create a true interface/implementation dichotomy that is > >important in the OO world. I've got the beginnings of an interface/implementation thing going with Perl 5, check out ex::implements and ex::interface. They're still not 100% there because I haven't actually written any real documentation, and there can be problems with pre existing AUTOLOADs for the non 'utterly strict' version, but there's the beginnings of something decent. At least you now get an error thrown at compile time if you haven't actually implemented everything you promised to implement. But until 'my Dog $spot' becomes an assertion that $spot can only be either undefined, or something that implements the 'Dog' interface, my code is just an experiment. Albeit a possibly useful one. > That's because of the way most people implement their classes. Perl does > have a concept of private date (although it's not built into the language > as that) and it's actually fairly easy to get that. OO Programming with > Perl by Damian Conway has plenty of example demonstrating that. All hail Class::Contract. Slow as a dog 'cos of all the tie magic, but *utterly* fantastic otherwise. Again, fingers crossed for Perl 6 making 'tie' or its moral equivalent nice and fast. And there's so much in Perl that makes OO so *nice*. For instance, I have a container class (It's a row in a shopping basket) that can be fully specced completely independently of the stuff it contains and yet, because of AUTOLOAD and 'can' it can present itself as if it were the contained object to stuff that is expecting that. Which reminds me, I really need to overload the container's 'isa' method so that it can return true to C<$container->isa('Contained')>. But then another problem arises: Because C<{}->isa(...)> throws an exception, too much code ends up doing C. Good, friendly polymorphic behaviour would have C<$unblessed_ref->isa(...)> and C<$unblessed_ref->can(...)> returning sensible values. Some sort of $random_ref->is_blessed() method might be handy too. And here we are, too late for a perl6.language rfc... -- Piers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection (and a proposal!)
kyle dawkins <[EMAIL PROTECTED]> writes: > On Wed, 06 Dec 2000 05:52, Matthew Byng-Maddick wrote: > > > 6. Engineering > > > The Perl community is made up of a truly eclectic group of people, which > > > is an amazing strength. However, it's also an amazing weakness: I get > > > the impression that very few programmers in the Perl community spend a > > > lot of time *reading* books on software engineering and techniques > > > thereof... and > > > > I'm not convinced about this. Although from my limited experience, I'm not > > very fond of them > > Hmmm, I'm not sure if you're talking about the programmers or the books. Ha. > But seriously, I lose a lot of respect for people who don't continually > study software engineering yet call themselves developers. Our craft is > constantly evolving, and to ignore the material that's available to us to > learn new techniques is completely irresponsible and it leads to some of the > problems that we are bemoaning in this very thread. I admit I read these kinds of books fairly often, although because of the sites I do they can tend towards more general topics (Funky Business, Cluetrain Manifesto), but Extreme Programming and Rapid Development are two of the bibles. I have to say though, I've avoided the Design Patterns type books purely because of the C++/Java bias. That said, anyone who hasn't digested Damian Conway's OO Perl book is a total slacker. *snip* Dave -- Dave Hodgkinson, http://www.hodgkinson.org Editor-in-chief, The Highway Star http://www.deep-purple.com Apache, mod_perl, MySQL, Sybase hired gun for, well, hire - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection (and a proposal!)
At 14:07 06/12/2000 -0500, kyle dawkins wrote: >Ok, you're missing my point but that's partially my fault for not explaining. > First, let me agree: Java's "everything is an object" mentality sucks >balls. And yes, Perl's duality of functional/OO is really nice. Taking that >away is not what I am advocating... I think there should be the *option* in >Perl to disable certain features that make Perl a dangerous language for OO >development. First and foremost, the lack of true encapsulation is >disastrous. There is no concept of private data because instance data is >stored in a blessed hash (typically) that's open wide to the world. It makes >it tough to create a true interface/implementation dichotomy that is >important in the OO world. That's because of the way most people implement their classes. Perl does have a concept of private date (although it's not built into the language as that) and it's actually fairly easy to get that. OO Programming with Perl by Damian Conway has plenty of example demonstrating that. I also have an inheritable Class::ArrayBased somewhere on my disk that provides a framework for array based objects. Admittedly it's encapsulation through obscurity (so to say) but people that understand how it works will probably respect the encapsulation, while those that don't will fail to access the content as a hashref. -- robin b. Make it idiot proof and someone will make a better idiot. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection (and a proposal!)
On Wed, 06 Dec 2000 05:52, Matthew Byng-Maddick wrote: > > 6. Engineering > > The Perl community is made up of a truly eclectic group of people, which > > is an amazing strength. However, it's also an amazing weakness: I get > > the impression that very few programmers in the Perl community spend a > > lot of time *reading* books on software engineering and techniques > > thereof... and > > I'm not convinced about this. Although from my limited experience, I'm not > very fond of them Hmmm, I'm not sure if you're talking about the programmers or the books. Ha. But seriously, I lose a lot of respect for people who don't continually study software engineering yet call themselves developers. Our craft is constantly evolving, and to ignore the material that's available to us to learn new techniques is completely irresponsible and it leads to some of the problems that we are bemoaning in this very thread. > > that lack of knowledge tends to bleed over into a lot of code out there. > > We have a HUGE problem in the community of the "coder superstar" > > mentality... > > yup. > > > which is very dangerous. Perl allows far too many tricks, and often code > > ends up totally unmaintainable and unreadable because some coding yahoo > > put in some glory-code. It happens in many languages, true, but Perl is > > the ideal environment for it. > > Not necessarily. You can get coder superstars who write maintainable and > understandable code. OK, terminology problem... I wouldn't call them "coder superstars" *if* they write maintainable and understandable code. Perhaps I should have called them "glory coders" instead. You're totally right, there are plenty of great coders out there who conform to coding standards and don't write tricky code. But what I mean is that there is an abundance of glory-coders in the Perl community because, in a way, the community encourages it. That doesn't fly in a large-scale project and greatly reduces the chances of mod_perl being adopted in the enterprise (IMHO). > > * We implement a "mode" under mod_perl, kind of like "use strict", that > > suddenly forces Perl to behave well from an object-oriented standpoint. > > By this, I mean taking some of the power away from Perl that causes > > trouble, like allowing anyone to write instance data on an arbitrary > > instance of a class... > > No. no no no. Forcing perl to behave as "Object oriented" is entirely the > wrong thing. This is why Java sucks so much. "Everything is an object" > (excepting, obviously, the language primitives). Perl is nice because you > can write it functionally or object oriented depending on the problem > you're trying to solve. Also this functionality is more core Perl than > mod_perl. Ok, you're missing my point but that's partially my fault for not explaining. First, let me agree: Java's "everything is an object" mentality sucks balls. And yes, Perl's duality of functional/OO is really nice. Taking that away is not what I am advocating... I think there should be the *option* in Perl to disable certain features that make Perl a dangerous language for OO development. First and foremost, the lack of true encapsulation is disastrous. There is no concept of private data because instance data is stored in a blessed hash (typically) that's open wide to the world. It makes it tough to create a true interface/implementation dichotomy that is important in the OO world. > > * We "homogenise" some foundation classes. This means we create a > > *suite* of classes that have consistent API, are designed together as a > > framework, and are easy to learn > > I think you need to get out of the "object-oriented-only" mentality. But > yes, sort of, agreed. U, remember, this thread is about mod_perl advocacy. In my mind, we will have huge problems encouraging enterprise adoption of mod_perl without some fundamental changes. No enterprise in its right mind would choose a platform that is not OO for any large project these days. Regardless of whether you like this or not (and I can tell that you don't), it's the truth... you said it yourself. In order to fight the Java juggernaut, we have to beat them at their own game. Perl has so many advantages over Java that that shouldn't be a problem, yet it is. Primarily, it's one of perception... Perl is a scripter's language, Perl is for hackers, Perl is great for sysadmin tasks... but it's also a technical one. Java has a set of foundation classes that everyone uses. They suck festering balls, but they're there. We can learn from that and build a set of consistent classes that allow developers to build web *apps*, not a shitload of scripts that kinda work together as glorified CGI, which is what we get all too often now. Yes, Java is a sorely broken language, but it's being adopted, partially because of Sun's hype but also because it offers enterprise developers real ways to encapsulate their business logic proper
Re: RFC: mod_perl advocacy project resurrection (and a proposal!)
I've always considered mod_perl similar to an artist's canvas, while Java is more like a craftsman's tool kit. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection (and a proposal!)
Matthew Byng-Maddick wrote: > > On Tue, 5 Dec 2000, kyle dawkins wrote: > > * We implement a "mode" under mod_perl, kind of like "use strict", that > > suddenly forces Perl to behave well from an object-oriented standpoint. By > > this, I mean taking some of the power away from Perl that causes trouble, > > like allowing anyone to write instance data on an arbitrary instance of a > > class... People are looking at this sort of thing. Damian Conway wrote Tie::SecureHash and Class::Contract, which may be driving at this sort of thing. The latter implements "design by contract", as seen in Eiffel. I read Damien's paper on it, but haven't used it - there are four things that put me off: 1. The difficulty of modifying existing classes to work with it 2. The magic of "flyweight scalars", which I haven't yet got my head around 3. "This code is funky"-type disclaimers scare me. 4. It looks like he just defines "data types" as LIST, ARRAY, the usual Perl primitives. This is of limited use, IMHO; being able to _define_ rules for data types (eg. valid URI; reference to FooID in table Foo in database bar) would be more powerful. (Not that these should all be checked every time, unless you're implementing a Snail, but C::C does have the ability to switch checks off, eg, in a live environment. Though live users make very thorough testers :-/) I can see why people want encapsulation, though I've rarely seen problems due to people violating it. This may be pure luck. *Lack* of encapsulation may provide clues when you hit something with Data::Dumper & find out what's going on on the inside. IMHO, assertions, data type definitions, pre & post conditions are v. useful things. Define interfaces to methods & functions. This isn't necessarily the right approach - especially at the beginning of a project - but it is in some cases, and AFAIK there is little to automate this stuff available in Perl. Putting up these walls can *really* help isolate problems. Eiffel & Class::Contract allow conditions to be *inherited*. So these approaches work hand-in-hand with OO *and/or* re-use. Cheers -- Tim Sweetman A L Digital 'Now you see this one-eyed midget shouting the word "now"...' --- Bob Dylan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection (and a proposal!)
On Tue, 5 Dec 2000, kyle dawkins wrote: [1. two types of developer] agreed. [2. Perl4 / Perl5 ] This is also true. Although a lot of "Perl programmers" haven't got a clue about the object orientation stuff in Perl5 either. On the other side of the coin, too many people are jumping on the "It's object oriented, it must be reusable" and "The only way to solve problems is using objects" bandwagons. Java and C++ both play to these. And unfortunately they've convinced management, in general. Plus, big corporates like to deal with corporates - Java is defined by Sun, a corporate. This is always going to make our life hard... > 3. Installation/setup > Ok, so if you have Linux, it's a piece of cake... download all the sources, OK. but s/Linux/a UNIX or UNIX-alike/g. > follow the README's, and go. But what if you don't have Linux? Or you > aren't root, and what if you need access to httpd.conf to keep changing Then you don't necessarily do it on port 80. This is the only reason you need to be root. > stuff? And developers are going to need to cycle the server all the time, so > they need the ability to do that, too... it's definitely a weak point. I can > install any one of the Java-based web application frameworks and be > developing immediately. I disagree. The webserver stuff still needs to be run as root, or you run it on a different port. Although I would also suggest having a look at userv (http://www.chiark.greenend.org.uk/~ian/userv/), although there are some security holes opened up by using mod_perl. > 4. Isolation > A lot of mod_perl projects (or even Perl projects in general) tend to be > one-person shows... maybe I'm wrong, and I'd love it if people could correct > me! But in my observation, we have a lot of programmers working in > isolation. This is bad. http://codix.net/. > 5. Foundation libraries > Because of the open nature of the CPAN community, there are a lot of great > modules floating around out there. However, there is no real API consistency > in them, and this will cause newcomers to Perl a fair amount of trouble. > Moreover, we're not going to get anywhere in the enterprise if people insist > on using HTML templating systems that allow the embedding of code within > HTML. It's straight up and down a total disaster and no right-minded > software architect would ever consider it. Agreed. > 6. Engineering > The Perl community is made up of a truly eclectic group of people, which is > an amazing strength. However, it's also an amazing weakness: I get the > impression that very few programmers in the Perl community spend a lot of > time *reading* books on software engineering and techniques thereof... and I'm not convinced about this. Although from my limited experience, I'm not very fond of them > that lack of knowledge tends to bleed over into a lot of code out there. We > have a HUGE problem in the community of the "coder superstar" mentality... yup. > which is very dangerous. Perl allows far too many tricks, and often code > ends up totally unmaintainable and unreadable because some coding yahoo put > in some glory-code. It happens in many languages, true, but Perl is the > ideal environment for it. Not necessarily. You can get coder superstars who write maintainable and understandable code. > --> SO <-- > I hope you guys can give these points some thought. I could be "smoking > grass" but I think I'm on target on most of my points and I'd love to hear > what you guys think too. In the meantime, here are some ideas that might go > down well (or not!): Not entirely. > * We implement a "mode" under mod_perl, kind of like "use strict", that > suddenly forces Perl to behave well from an object-oriented standpoint. By > this, I mean taking some of the power away from Perl that causes trouble, > like allowing anyone to write instance data on an arbitrary instance of a > class... No. no no no. Forcing perl to behave as "Object oriented" is entirely the wrong thing. This is why Java sucks so much. "Everything is an object" (excepting, obviously, the language primitives). Perl is nice because you can write it functionally or object oriented depending on the problem you're trying to solve. Also this functionality is more core Perl than mod_perl. > * We "homogenise" some foundation classes. This means we create a *suite* of > classes that have consistent API, are designed together as a framework, and > are easy to learn I think you need to get out of the "object-oriented-only" mentality. But yes, sort of, agreed. > * We need to drop-kick DBI out of the park... it's not that it's bad (it's > actually great... kudos to the DBI crew) but kind of the opposite; it's so > easy to use that most people don't think beyond it. How many of you have > ever thought about implementing an Object-Relational middleware layer using > mod_perl? We could create a set of generic OR classes as part of our > foundation framework.
Re: RFC: mod_perl advocacy project resurrection (and a proposal!)
On Tue, 5 Dec 2000, kyle dawkins wrote: > * We need to drop-kick DBI out of the park... it's not that it's bad (it's > actually great... kudos to the DBI crew) but kind of the opposite; it's so > easy to use that most people don't think beyond it. How many of you have > ever thought about implementing an Object-Relational middleware layer using > mod_perl? We could create a set of generic OR classes as part of our > foundation framework. Please take a look at: Alzabo (alzabo.sourceforge.net) - my own project Tangram (www.tangram-persistence.org) Those two are both very ambitious in terms of multiple DB support and complete abstraction. There are a number others that in a similar vein that are less ambitious (IMO): Class::DBI DBIx::DBSchema BingoX::Carbon DbFramework Those are all on CPAN. Of all of them, Tangram is by far the most mature. It is also actively maintained. I know that the first three on the bottom list, as well as Alzabo, are also being maintained. -dave /*== www.urth.org We await the New Sun ==*/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection (and a proposal!)
Everybody This whole call for mod_perl advocacy is definitely a good thing. But we're not going to get anywhere unless we understand the problem in detail. We can run around all we like talking numbers and touting the virtues of mod_perl but it's not going to actually do anything unless we address some fundamental issues. I don't claim to know the answers to these problems, but I do think I can at least start the ball rolling the right direction to get others thinking about what next. If we're on this list, there's a good chance we think we have a good understanding of mod_perl. Or at least a good understanding of the parts of the massive mod_perl beastie that we use. I use it all day every day but don't claim to know anything about Authentication, for example. I'm sure I could read the chapters in the eagle book and figure it out, but I don't know anything about it now. So, making that assumption, I want to bring up a few issues that I see as crucial. 1. We are worried that mod_perl is not being adopted as a server technology in enough places. This is actually TWO problems, not one, and to treat is as one is missing the point. There are TWO different kinds of developer out there. The first is someone who is probably not a programmer by trade, but has picked up CGI and/or PHP/ASP programming from a "21 days" book or by reading through examples. There are a number of reasons why *these* people have not jumped all over mod_perl... I'm sure we all know what those reasons are.The second group of people are *engineers* (or *developers*). These people need something different out of mod_perl. They need good docs, examples, stability, community support, and FOUNDATION CLASSES (more on this later) 2. Perl Let's face it, we love Perl, but a lot of people don't, because *they don't understand it*. Remember, a lot of people might have looked at Perl 4 when it was a disastrous hodgepodge and not looked at it since. Perl 5 is an infinitely better language than 4, but most people don't know that. In order for Perl to be acceptable in larger institutions with an already-established software engineering group, changes to Perl itself need to be made. See more below. 3. Installation/setup Ok, so if you have Linux, it's a piece of cake... download all the sources, follow the README's, and go. But what if you don't have Linux? Or you aren't root, and what if you need access to httpd.conf to keep changing stuff? And developers are going to need to cycle the server all the time, so they need the ability to do that, too... it's definitely a weak point. I can install any one of the Java-based web application frameworks and be developing immediately. 4. Isolation A lot of mod_perl projects (or even Perl projects in general) tend to be one-person shows... maybe I'm wrong, and I'd love it if people could correct me! But in my observation, we have a lot of programmers working in isolation. This is bad. 5. Foundation libraries Because of the open nature of the CPAN community, there are a lot of great modules floating around out there. However, there is no real API consistency in them, and this will cause newcomers to Perl a fair amount of trouble. Moreover, we're not going to get anywhere in the enterprise if people insist on using HTML templating systems that allow the embedding of code within HTML. It's straight up and down a total disaster and no right-minded software architect would ever consider it. which brings me to... 6. Engineering The Perl community is made up of a truly eclectic group of people, which is an amazing strength. However, it's also an amazing weakness: I get the impression that very few programmers in the Perl community spend a lot of time *reading* books on software engineering and techniques thereof... and that lack of knowledge tends to bleed over into a lot of code out there. We have a HUGE problem in the community of the "coder superstar" mentality... which is very dangerous. Perl allows far too many tricks, and often code ends up totally unmaintainable and unreadable because some coding yahoo put in some glory-code. It happens in many languages, true, but Perl is the ideal environment for it. --> SO <-- I hope you guys can give these points some thought. I could be "smoking grass" but I think I'm on target on most of my points and I'd love to hear what you guys think too. In the meantime, here are some ideas that might go down well (or not!): * We implement a "mode" under mod_perl, kind of like "use strict", that suddenly forces Perl to behave well from an object-oriented standpoint. By this, I mean taking some of the power away from Perl that causes trouble, like allowing anyone to write instance data on an arbitrary instance of a class... * We "homogenise" some foundation classes. This means we create a *suite* of classes that have consistent API, are designed together as a framework, a