Open perlpilot opened 6 years ago
I'm visiting Minimum Viable Perl in isolation... I don't agree with @perlpilot 100% on the point that most visitors to MVP will be doing so in isolation, but I can agree with his conclusion from my perspective; I want to get up and running with Perl ASAP, and preferably with the minimum viable amount of libraries (Perl core/standard APIs). I'm not under duress, but I definitely want to find answers to doing X && Y in Perl as soon as possible.
So far, I'm loving the 'book'. Keep it up!
Thanks @perlpilot and @naltun for the feedback. I knew I'd get some comments about this. :)
@perlpilot is your preferred method of dealing with file io open()
?
You are right. Even if I don't like open()
developers are going to need to understand it. And for some environments there is overhead to Path::Tiny
because you have to install it. I should at least link to the documentation for open()
and close()
. Thats my immediate solution to this because its super easy (see https://github.com/kablamo/mvp.kablamo.org/commit/a89f2bd7cf4f0d762b9cdafe3a32503f427a88a1 and http://mvp.kablamo.org/basics/files/).
MVP is definitely missing articles on many topics. open()
is probably one of them. I have a similar problem with Test::More
-- I only documented Test2
but most tests in the wild use Test::More
. I hope to address those holes at some point.
For this initial release I wanted to recommend a good solution for file io and leave out all the many other solutions in order to keep things simple for myself -- at least until I've seen if people find my idea/writing useful.
I also hope to grow MVP with more articles about "advanced" topics like templates, plack, async, etc.
If the writing stays concise and the site remains simple, then I think more articles is ok and I'll still be staying true to the original idea.
I think that you think the audience for this book I’d a Pythonista who has been handed some old Perl code to add functionality to and it’s not important enough to rewrite in Python and I agree with you. But I think there’s another audience. It’s the same as above but there’s a bug and it needs to be fixed ASAP. From that perspective you’d absolutely need to describe open() and built in stuff before moving to encapsulating modules like Path::Tiny. Just keep that in mind, there’s two audiences, IMNSHO. :-)
Thanks for the comments. They are helping me think through things and are helpful.
I agree and I want to address both audiences. Path::Tiny should not be in the "Basics" folder. I'll need to find a better place for it.
I've been reluctant to spend lots of time on built in functions in these early days because I feel like they are documented passably well in the official perl docs. But I'm sure people are lazy to scan the list of built in functions so I want to have at least a few articles on that stuff. I think initially there will be 3 such articles:
I'm sure that over time there will be more.
The opening sentence to this section is:
Um ...how so? And then you suggest Path::Tiny which I find "strange".
Are most people that are going to visit Perl going to do so in isolation? I don't think so. I think they're going to visit Perl under duress. They have a project that is partly written in Perl and they need to modify the Perly bits but they don't quite know what to do. The code they're going to touch probably won't be using Path::Tiny (I mean it might, but I bet there's far an away more Perl code out there that doesn't use Path::Tiny than code that does use it).
Perhaps your book isn't geared towards these people, but I think those are the people to which your book will be most helpful.
Anyway, my two cents.