Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

comment on

( [id://3333]=superdoc: print w/replies, xml ) Need Help??

I ++ you for obviously putting a lot of thought into it, but I have to argue with a lot of what you say.

First I'd like to make a clarification. You seem to compare on one hand the whole Perl language with on the other hand specific solutions in other languages. PHP is a hypertext preprocessor. Ruby on Rails is for creating web applications. Java is a general-purpose language, but its web solutions are as myriad as Perl's and at least as complex and confusing (in true enterprise spirit).

I think it boils down to corporations (well, everyone) wanting to minimize risk

Then those corporations can contribute to creating their own solutions. Some of them may even be wildly successful and become a canonical solution.

TIMTOWTDI is fun and all ... all of these myriad solutions create confusion in newbies that they wouldn't have elsewhere.

Newbies will be confused in any case because they're newbies.

And there are myriad problems. You want there to be one problem that you can solve with The Solution, but there isn't.

PHP has The Solution. Perl has many solutions, advocated by different people for different things. They're supported differently. They may fade away and be replaced. You could make the wrong choice.

It may seem right now that PHP has The Solution, but I think you're wrong. The Problem is not a single unchanging thing. For example, how do you do "AJAX" in PHP? I don't know, and maybe there are good solutions now, but I'd bet that three years ago there weren't any The Solutions for it. There might not even be a good solution in Perl, but I doubt that trying to solve every possible problem with The Solution is going to lead to a good solution.

Similarly I think that in five years Ruby on Rails will start to seem creeky. It's all the rage now, but the problem space will change, people will want different features. Ruby on Rails, and these kinds of The Solutions, will be unable to adapt; they require you to conform to a predetermined set of conventions. There was an article I read recently in some Linux magazine which went on about how "constraint equals freedom", referring to how the conventions in Ruby on Rails let you worry about other things. The problem with this, I think, is that you can't rely on other people to know what your problems are and will be in the future. And when you need to come up with a better solution for something, you don't have a good foundation on which to build it.

Say you want to create a new class to store some data. Ruby is easy. Just define your class and you're done. Perl makes you worry about blessed hashes or arrays or scalars or coderefs or inside out objects or whatever else. You could choose wrong. This is a fundamental basic part of the language that you could potentially screw up and make your life miserable about later on.

I don't agree that it's fundamental. If you want a safe solution, you bless hashes. With Ruby, according to what you're saying (I have no idea), you apparently don't even have an option. I'm not sure why this is better.

I went to one of the talks on inside out objects at YAPC this year and it was a good show. But I was also sitting there thinking, "I shouldn't need to care about this stuff."

You don't. There are other solutions. You can wait for a couple years, see if the inside-out objects fad pans out, then start using it if it turns out to be all that and a bag of potato chips.

You also don't have to stay with Perl. It may be that it's doomed as far as web development goes. If that's what you do and what you think about it, why stick with Perl? There are apparently already solutions to your problems. Why are you reinventing those wheels in Perl?

Maybe it's a documentation and community issue. Maybe introducing users to simply blessing hashrefs as objects is the right approach and having a footnote that it can actually be anything and they can read more at XXX is all it would take.

I'm not sure where you got the impression that things were otherwise. You go to Perl conferences, so yes you're aware of the more advanced object-oriented techniques, but most books and the perldocs like perlboot and perltoot use hashes. Maybe you're basing things on one specific books, "Perl Best Practices"? I personally don't agree that inside-out objects are a best practice. They seemed more like "something Damian thought was cool at the time".

Perl's flexibility is one of its greatest strengths, but it also makes it pretty scary to new users. So how can we minimize risk for them and make them feel comfortable that they're making safe choices?

I don't think we can. They're newbies. They're going to make catastrophically bad choices due to their lack of experience.

I don't need to go out and buy a book to know how to do templating in PHP, and I shouldn't need to buy one for Perl, either.

Like I said above, I think you're comparing apples and oranges. Perl is a general-purpose programming language. PHP is made for preprocessing HTML.

I also disagree that you won't have to do a lot of hard reading to be able to do templating well in PHP. Yes, you can slop something together, no problem, but you can (and many people do) do the very same thing in Perl. You can't just download a training program into your brain like they do in The Matrix.

The community is also right out. People bicker and argue and have different opinions. Let everyone who uses perl put their two cents in towards defining The Solution(s), but have a clear list of what those recommended solutions are

There will never be such a list unless a dictator comes out and demands that everyone else accept their list as the canonical one. Everyone else won't. You want to put Catalyst on the list? Why not the replacement that its former lead developer forked off? Why not Jifty? Why not recommend more common low-level modules like HTML::Mason, Template::Toolkit, HTML::Template? You want to put XML::LibXML on the list? Why not XML::Twig, XML::etc... Want DBI? Why not DBIx::whatever or Class::whatever?

Now if you wanted to assemble a big matrix comparing all the options, explaining their relative strengths, features, weaknesses, that'd be great.

Well, I'm getting tired and have work to do, so I hope that didn't come off as trollish. Good luck.


In reply to Re: Perl needs The Solution by ForgotPasswordAgain
in thread Perl needs The Solution by jimt

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":



  • Are you posting in the right place? Check out Where do I post X? to know for sure.
  • Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
    <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
  • Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
  • Want more info? How to link or How to display code and escape characters are good places to start.
Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others browsing the Monastery: (3)
As of 2024-03-19 05:17 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found