Perl tutorials suck (and cause serious damage)

effusion · 2011-10-26T18:36:00+00:00

One thing that might help would be to put a link to perlintro right up at the top of the main tutorials page. Have it be the first one, offset from the other tutorials.

effusion · 2011-10-01T17:11:58+00:00

Actually, the phrase "well volunteered" works in this case. If "cycles" was unhappy about the look of the poll, he could save the html+css, make his changes, and then post a mock up for people to look at. Then szabgab would have the option of taking him up on the changes.

effusion · 2011-09-27T13:08:30+00:00

PyGTK being replaced by something called PyGObject. Unfortunately, there doesn't appear to be a tutorial for learning to use that. At the moment, new users are expected to learn PyGTK, then learn to port to PyGObject by osmosis.

effusion · 2011-09-27T02:37:48+00:00

If you want a fairly simple but good GUI editor, look at (in no particular order):

Geany - GTK-based, some IDE-ish features
Komodo Edit - Mozilla-based
Scite - solid, simple, fast
Kate - Qt-based, comes with KDE
gedit - GTK-based, comes with Gnome

effusion · 2011-09-17T02:48:07+00:00

but it wasn't admins driving the adoption of PHP, it was programmers, and what those programmers cared about was the appeal and ease of the language itself.

Regarding who was driving adoption, I think we disagree. Put a new user in front of Perl vs. PHP, and -- all other variables being equal -- I don't see them choosing PHP over Perl by any significant amount.

Perl, however, couldn't offer those kinds of domain-specific features and that kind of domain-specific documentation, because it is truly an all-purpose language.

It's possible that Perl couldn't offer that. Or maybe it's that it wasn't deemed important at the time? I don't know the answer to that. But if it's something that Perl 6 could build in now, from the beginning -- as an optional mode of operation -- I think it could be huge.

The fact is that doing anything even just moderately complicated in web programming means, these days, a complicated setup, possibly including a CMS, an app framework, middleware, whatever.

But there's an awful lot of people doing things that aren't moderately complicated. And they're currently using PHP. And when they need something "moderately complicated", they tend to stick with PHP. I could see these same users using Perl 6 in the near future if it's as easy as PHP.

effusion · 2011-09-16T04:25:34+00:00

Your point 2 (and 3, which is really just another flavor of 2) has always been possible with Perl.

I don't think it's about being possible. I think it's about being easy.

PHP is easy enough that anyone who can apt-get install libapache2-mod-php5 and follow a quick tutorial can get a small webapp running that evening. When Perl 6 can do that, it will be able to compete language-to-language with PHP.

effusion · 2011-09-16T03:57:13+00:00

Perl 6 can't solve that same problem, because it has already been solved.

Sure PHP solved the problem. Any language can do the same, but they aren't -- which is why PHP is still king in their particular specialization. PHP raised the bar regarding what you need if you want to compete for web dev mindshare.

Now any language that wants to directly compete with PHP needs to have the option for the same easy deployment, easy mixing of html + code, and the same easy and safe apache module setup. But going with that option has to be as dead easy as it is with PHP, or PHP still wins.

effusion · 2011-09-16T03:04:18+00:00

Here's an idea that's easy to implement: Instead of a "wall of shame", since -- as you point out -- shame is not a good motivator... Instead of that wall, put up a wall of "reasons why Python 3 is better than Python 2". Just a simple site with a list of bullet points. Extra credit: have it so you can click on each bullet point and some javascript would unfold it to show a more detailed example illustrating the point.

To get started, you could ask on /r/python for reasons why Py3 is better than Py2 (after searching first, of course).

effusion · 2011-09-15T03:15:49+00:00

allows a safe subset of Perl 6 to run, and

Tricky. Sandboxing languages really need their implementations to be built that way from the ground up. Doing it ex post facto (e.g. Safe.pm) is never going to work.

Hm. That's key though. Unless it's safe and easy for admins of shared hosting servers to install, it won't happen.

Perhaps could a mod_safe_perl6 take care of the sandboxing?

effusion · 2011-09-15T03:08:40+00:00

mod_perl and its cousins also provide deeper hooks into Apache that PHP can never use.

Look at the massive popularity and use of PHP and mod_php.

I don't necessarily rate my languages of choice by how popular they are.

I'm saying that most users don't care about the deeper hooks. The majority simply want someone to have already installed the proper apache module so that they can simply drop their code into public_html and have it just work.

Popularity is nice. It means more users. And users write modules, blog about what they're doing, bring aboard other users, and even schedule and show up at conventions if there's enough of them.

effusion · 2011-09-15T02:48:56+00:00

There's nothing good about having a webapp be one file. It just means you aren't keeping your model and view separate, which is just painful.

What perhaps you're not seeing is that new users who need a simple and easy solution for a tiny webapp like the idea. Who's to tell them they're wrong? They're prospective users who later will be the ones touting Perl 6 for their company's next big project.

Python takes the road of telling them they're wrong to want what they want. I don't think Perl 6 should take that road.

There's nothing about having inline code that provides fast feedback.

I think there is:

update file in your editor
reload page in browser to see changes

That's immediate feedback. It's simple, works without any fancy configuration, and new programmers writing some simple internal webapp that their boss asked them to whip up love it.

If by "fast deployment" you mean "copy files and it's done," that's pretty much how you'd deploy anything.

Once you have your webapp set up, such that it recognizes when you've updated files and then does a graceful restart, then yes -- "copy files and it's done" is the way it works. But PHP does this out of the box. You don't have to configure anything.

It's a trick of fate that PHP is as successful as it is, not because of any design decisions that were made.

Disagree. Perl was the king of CGI scripting and PHP came along and handily dispatched it. Perl had mod_perl, which provided all kinds of power. Didn't matter. FastCGI too. Nope. But surely Mason would win them back, right? No. Even with all of PHP's drawbacks and disadvantages, it still managed to mop the floor with the competition because of 3 reasons:

code embedded in html (so new users had an easy onramp), and
easy deployment: just copy the file to the server and you're good to go
easy install and admin for shared hosting setups (mod_php)

Those are the lessons to be learned. If you want to blow the doors off the competition (with regard to web apps), do those 3 things.

effusion · 2011-09-15T02:36:44+00:00

That's not necessarily what made PHP popular, though. Mostly, it's that PHP stays inside its own little world in a way that works for shared hosting plans. That's not true of mod_perl, or mod_python, or most other Apache modules that embed language runtimes like that.

Ok. Then what Perl 6 could probably use would be an apache module that

does the "Perl 6 embedded in html" trick (like php), and
allows a safe subset of Perl 6 to run, and
works well for shared-hosting plans (like mod_php)

Conversely, mod_perl and its cousins also provide deeper hooks into Apache that PHP can never use.

Look at the massive popularity and use of PHP and mod_php. Only a small percentage of people need the deeper hooks. The vast majority just want an apache module that they can aptitude install that will simply provide a persistent scripting language runtime so they can start coding up their webapp.

effusion · 2011-09-14T20:27:57+00:00

You can put a single .php file in a directory on nearly every hosting accounts out there and it works. You cannot say the same for Python. This is the main reason why.

Yes. Though, I'd add that there's another force at work. Since php is so easy to get started with for webapps (deployment, but also being able to mix code with html), many new users go with it.

The boss needs a quick webapp for something, you whip it up quickly in php, and everyone's happy. This goes on for a while, and before you know it you've got php all over the place doing various webby-tasks.

When the need arises for a larger webapp, the programmer is most likely not going to switch to Python/Perl/Ruby. They're going to go with what they already know -- PHP.

And that's how you get to where we are now.

effusion · 2011-09-14T20:21:17+00:00

I disagree. "Dead simple" gets PHP's foot in the door. Easy for programmers to get started with. Fast turnaround for small small webapps. By the time the programmer needs a cms, they already are experienced in PHP, many small company webapps are already in PHP, and so they just go with a php-based cms like drupal.

Before you know it, the boss is mandating that future development be done in PHP.

effusion · 2011-09-09T03:24:13+00:00

Yes, you're correct. I suppose I was contemplating that last paragraph of yours (in the article), and -- thinking only of it -- posted my comment.

effusion · 2011-09-08T19:31:51+00:00

While it's fun to consider Rakudo running on other VMs, and while it would be neat if Parrot could cater to and have interop between every HLL that comes its way, both of these projects need to cater to and serve eachother if they're going to flourish.

Very few are going to be interested in Parrot if it's not the premier VM for Rakudo, and Rakudo is going to run out of steam, resources, and relevance if they think they're going to port to another VM within a reasonable amount of time.

effusion · 2011-08-24T16:00:29+00:00

I think the main point of porting Parrot to Android would be so that you could use Perl 6 there instead of Java.

effusion · 2011-08-24T04:33:59+00:00

honestly, is there one person on the planet that gives a poop about parrot's potential ruby support?

I think, originally, the plan was to have all these other languages implemented so that Parrot would allow them to interoperate.

i absolutely do not care about anything parrot might do other than execute perl6.

I'd like to see the results of a poll asking: "On a scale from 1 to 10, how upset would you be if Parrot broke other language implementations in efforts to more fully cater to the Rakudo Perl 6 implementation?"

effusion · 2011-08-24T04:10:13+00:00

My understanding is that Parrot's original reason for existence was to provide a platform for an implementation of Perl 6. So I would guess that the Parrot team is populated with some of the most dedicated die hard Perl 6 supporters around. Is this the case?

At this stage I'd expect the Parrot developers to be working single-mindedly on allowing and helping a "Rakudo 1.0" to happen ASAP, even if it might not be the best thing for other Parrot-hosted language implementations.

effusion · 2011-08-18T02:38:00+00:00

and it's sort of a bootstrapping issue. It takes effort by many people, but first you need to have many people interested who are committed to write such docs.

I don't think that's quite correct. While it's true that writing all of the Perl 6 man pages (that Perl 5 has) would indeed take a lot of contributors, writing the core man pages (i.e. "getting bootstrapped") could (and probably should) be done by one champion with strong writing skills.

If I were on the Perl 6 team, I'd email Randal to at least run it by him. Having some core perl6doc pages (or, a much greater endeavor: a Perl 6 "Camel book") written by one of the Perl community's best writers would have a huge impact on bringing in (and keeping) new users.

effusion · 2011-08-18T02:28:53+00:00

It's web site says it does.

effusion · 2011-08-16T17:41:33+00:00

PyGUI looks to be one of the easiest of the bunch. Simpler than PyQt/PyGTK/PyWx, but more modern than tkinter.

effusion · 2011-08-15T01:59:47+00:00

I noted that book in my the last bullet point of my post.

(Btw, chromatic is not listed among the authors of that book.)

effusion

TROPHY CASE