Do you remember web programming in the late '90s? I started in 1998, after mod_perl had just come out and people were excited that something better than "drop this program in a specially configured cgi-bin/ directory and set the permissions and check your error logs" had come about.
Getting even a simple dynamic web page working meant either learning enough system administration on your own to set up your environment or being fortunate enough to have a system administrator willing to set things up for you.
This all presupposes you were using something sufficiently Unix-like that all of the instructions you could find all over the Internet in those days would work for you; woe to you if you were a Windows user without access to a Unix-like machine.
(How things have changed; see Promoting Perl to Dissimilar Users.)
In these enlightened times, we have options besides the cgi-bin/ approach and mod_perl. We have Plack and Plack::App::CGIBin. We have PSGI-aware servers which require only Perl to run—no Apache or nginx or IIS, just Perl. We have Padre and Strawberry Perl and perlbrew.
We have all of the tools necessary to bundle into one or two downloads. We can give novices—especially novices on Windows—a good version of a modern Perl 5 with a good IDE which includes a plugin (I couldn't find an existing one, but I found a couple of close options, including Padre::Plugin::Plack) to make writing and testing little Perl web programs trivial.
I know if you're reading this, you probably feel like I do: developing on Windows is like doing scrimshaw blindfolded while wearing oven mitts. You probably feel like I do: the CGI approach is a crazy mismash of ad hoc protocols ripe for making messes. You probably feel like I do: Plack is such an improvement for Perl web programming that we should have stolen it from Python and Ruby before they invented the inspirations.
You may even feel like I do: IDEs have advantages, but my fingers know Vim (or Emacs) far too well to feel comfortable switching.
None of that matters. What matters is that we have all of the tools and a couple of people could spend a couple of afternoons putting things together to smooth the onramp for novices.
The Padre CGI compatibility plugin needs to be able to:
- start, stop, and restart a Plack server
- serve static resources from one directory
- serve .pl or .cgi files from a cgi-bin/ directory
- publish access and error logs to a specific location
That's it. The code to add a menu to Padre is longer than the Plack-specific code. It's 90% convention, and then almost all of the tedious beginning setup stuff at the start of even extant Perl CGI tutorials goes away.
Yes, these novices should eventually learn about Plack and CPAN. They should probably eventually learn about Unix and Unix-like hosting. They deserve to understand enough of Unix culture to get some of the parts of Perl that codify and clean up said culture.
Before that, though, let's let them get a few successes under their belts so they feel like they're welcome and wonderful and capable and interested in learning more because they can get results without first having to beat their heads against a culture and a learning wall that is only necessary because we haven't removed it for them yet.
... because it hurts me none if someone learns how to write code using Windows and it hurts me plenty if someone gives up on writing code because we've driven her away with trivial bugs it would take an afternoon or two to fix.
Ah, the "good" old days of when mod_perl was king. There were few alternatives of faster-than-CGI deployment mode (FastCGI was another), and Apache was practically synonymous with webserver. I remember the pain of getting mod_perl to work with Windows, as I was still using Windows for work, and there was no VirtualBox/VMWare.
I'm very thankful that we have Plack/PSGI nowadays. But at least I got to learn the Apache API and how a modular/hook-based system works.
I dont think this has to be newby specific. Veterans will also be happy with the reduced fiddle.
Like in Math - so often its nice to know how to do things from first principles, but most of the time you don't care you just want the outcome. The area of a circle for example, or volume of a sphere - most people know them (or know of them) - but few people could derive them from first principles, or even know enough about integration (or triple integration) to do so.
I propose that such an interface from padre to plack could be created in such a way that it could be attached to emacs, to vim, to geany (my preference), to eclipse (where newbies live), to notepad++, to codeblocks or whatever.
Perhaps even connecting to the test suite or making mechanize tests easier?
> you probably feel like I do: developing on Windows is like doing scrimshaw blindfolded while wearing oven mitts.
I develop fulltime on windows, targeting Linux, and i couldn't disagree more. If anything, developing on Linux makes me feel like i'm running blindfolded. What's worse, you're not the only to say this. I hear this sentiment not quite often, but also by far not seldomly, that Perl on Windows has issues, that Perl on Windows barely works, that Perl on Windows is flat out broken, blah blah blah ****ING BLAH.
You know what i hear when i hear such comments? "Hey, you, 12 year old kid wanting to learn some programming who has only her parent's computer available ... DON'T YOU DARE TOUCH PERL IT WILL BE PAINFUL! Better stick with Python or some other language where the community will welcome you instead of making you feel like an outcast."
I don't mind if you level an actual detailed criticism that can either be used by people with interest to improve the situation, or that can teach a person what needs to be avoided due to irreconcilable platform differences, like for example: "Perl fork on windows is entirely broken, because the Windows kernel does not provide the necessary features." or "Don't use threads if you plan to be cross-platform, because their implementation is extremely bad (due to them only being the backbone for the broken fork emulation)." In fact, i welcome it with open hands, because everyone loves a well-written bug report.
But if you feel the need to fall back on platitudes and handwaving ... just don't. Perl on Windows works.
By the way.. A "Modern Perl for the Web" would be very nice!
I'm glad to hear Perl on Windows works.
I've developed on Windows--as recently as last year. I can't imagine anything more hostile to development, even Mac OS X. I'm glad it works for you. It doesn't work for me.
Improving the situation would require better window management, the GNU utilities, a package manager, and the expectation to have a working C compiler and toolchain and development headers available and easily installed. I don't see that happening (Cygwin notwithstanding).
> hostile to development
> better window management, the GNU utilities, a package manager
Important to realize here is that, while i agree these factors would push away someone used to *nix, they are merely a subjective personal OS preference and have no bearing on "Perl on Windows". Many people seem to be conflating those into one.
There is a very real and important difference between "I don't like how Windows works." and "Perl does not work on Windows."
Also, let me tell you, from my point of view all modern OSes are bullshit through and though, thanks to me growing up with an Amiga. I'm still waiting for an OS that gets ASSIGN right. I don't trot that out at every opportunity i can though.
Some advice on the points you mentioned in any case:
- Window Management
I'm honestly happy with the way Windows does things, however i found AllSnap to be a worthwhile addition: http://ivanheckman.com/allsnap/
- GNU utilities
This one's easily solved by installying Cygwin. I use tools like grep regularly from the command line. On that note, it helps to have a file manager that can spawn a command line easily on the current directly, like Total Commander.
- Package Manager
This one's hard, yes. If you want to compile something like XML::LibXML you have to go and find the corresponding libs and headers manually and copy them into the appropiate places. That sucks. I'm hoping that Joel Berger's effort with Alien::Base will mean that such things will soon move to a useful and cross-platform package manager, i.e. CPAN.
- C compiler
That's really easy though. MinGW is easily obtained and installed, and if it's not already present, both ActivePerl and Strawberry Perl bring their own compiler, so in most cases you shouldn't even need to think about this.
Hmm, in retrospect, you didn't actually mention Perl on Windows. Sorry for being overzealous on that count.
I hope my personal preference not to develop on Windows doesn't get in the way of hoping (and trying to help) Perl works well on Windows. The easier installation and CPAN management works, the easier I can explain "Do this small amount of setup and you can follow everything else in this book".
That's good for everyone.
The point, though, is that despite my preference not to use Windows, attracting more Perl programmers means reaching them where they are--Windows.
That's actually a fairly good point. Sometime i should sit down and go through your book from a virgin Windows installation to see where the sticking points are. :)
Everytime I try and get Devel::REPL to install on windows it fails due to the dependancy http://search.cpan.org/~lbaxter/Sys-SigAction-0.15/lib/Sys/SigAction.pm
Apprently that requires tty from linux. Would be good to have Devel::REPL available for windows users without this dependancy.