Hi, I am a Storage Administrator. I was on a lookout for a scripting language that would help me automate some of the work that I do. Started learning Perl, but it was ( and still is) a sort of intermittent process. Work load has a tendency to mount when you least expect and I end up not learning/writing Perl for days together.
Signed up here to write about Perl. I am still in the learning phase, yet, I'll post whatever small scripts I write.
It saddens me when, without any valid research, some people, even a few of my colleagues bemoan the state of Perl. They think that Perl is stagnant, that its not "alive and growing" any more..In my own small ways, I am trying to change that perception. If I can get a few of my colleagues and friends to change their opinion, it would be fine by me :)
Every year I count the number of jobs posted to jobs.perl.org (and sometime last year I put it all in github). I make no hard interpretation of these numbers and don't take them to mean anything. I think the rise in numbers up to 2006 are merely from people finding out about the service. I have no thoughts on the decline after that.
A fairly cheap kludge to encode metadata into a Git repository would use special directories that link to the files that need metadata. (I suggest prefixing the directory names with "...", as that is ignored by default in some popular OS shells.)
An example of this is probably easier. Say we have
jenkins.our-config
and
git.our-hooks
in our repo
configuration
:
configuration
jenkins.our-config
git.our-hooks
We want to include that both files are about our production server. If we set up a directory structure in the repo like this:
This is my take on the version debate. Bear in mind that I'm not a p5p nor a Perl 6 developer, so I don't get a vote. I can still have an opinion though...
Perl 6 represents the future of Perl. But given the amount of time taken to get to where it is today, and the amount of work still needed before it can be put forward as a serious replacement for Perl 5, it realistically represents the distant future of Perl.
Anybody else interested in starting a perl devops mailing list or other group - there is a load of cool stuff out there, and few people have heard of half of it - would be nice to be able to keep up to date, discuss ideas, etc.
Good example : rexify.org - wish I'd heard of this sooner, would be even cooler to hear about people's experiences with it too
play-perl.org is up.
It's a very, very early alpha. There are no achievements, no news feed (Upd: news feed is in), no pre-set quests, not enough quest metadata and almost no introductory texts.
Still, I chose to release what I have now, because I want to start dog-fooding it myself, and because I want to see if anyone will care enough to try it.
(Also, my self-inflicted deadline was February 1st; I wanted to launch it with more features, but other projects and procrastination got in the way, as usual.)
TL;DR: Not if it can never have a major release. Please read on.
Note: I’m now not talking about soon, or what it would be named/numbered. I’m talking about ever.
Let me tell you my story, some of you may know it. I’m a Ph.D. candidate in Physics. Programming is woefully ignored in science education now. All my professors learned FORTRAN in courses during their Ph.D. (or B.S. in some cases) but now, given the ease of Mathematica, we seem to be expected to pick it up as we go on.
One day I had a nutty idea, I wanted to parse one of the temporary files created during LaTeX compilation. A friend, who knew next to nothing about Perl, suggested I needed Perl and Regexes. I can here you out there, saying “now I had two problems”. Not so. I learned, I improved and finally my first Perl script was out in the world. It doesn’t bear much resemblance to its current form but it worked.
So I have been avoiding talking in public about what Moe is, mostly because I would much rather spend my limited free time actually writing code rather than talking about code. But seeing it mentioned in a number of the Perl 7 discussions and often mischaracterized, I felt it was the time to say a little something.
Moe is a thought experiment to try and envision what Perl 5 might evolve into as a language and a runtime. It borrows much from Perl 6, but still aims to be true to its Perl 5 roots.
And that is all that it is (for now).
I am drawing my inspiration from the Pugs project in that Pugs was an experimental version of Perl 6 to help drive the language development forward, and I am trying to do the same thing with Perl 5.
Maybe it will work, maybe it won't, but we will never know unless we try.
I heard back from Andy Orr and Aaron Mitti, and they were happy for me to put in some work and a fresh release - already created the github repo and outlined a brief roadmap.
Once upon a time, in August 2012, there was a Perl Reunification Summit in the town of Perl, near Schengen.
Back then a couple of people have wrotten about it and today finally I have also posted about my experience.
I think it might be a good time to remind everyone about that meeting and link to the posts I found.
This hype about Perl 7 is so amazing, and even resembles the time when Perl 6 was around the corner :-) It's extremely interesting to read new posts and comments. Sometimes I find there thoughts similar to mine that I had a few minutes before reading that.
A guy in Moscow.pm mailing list gave another bright idea (RU) of why the "7" would be useful. This will help in communication with a sysadmin when they say in response to a request to install a new version of Perl: Hey, there's Perl 5 on the server already, what do you want from me?.
I would like to dedicate a time slot in the schedule of this year's YAPC::Europe for an open discussion of Perl versioning :-)
Also, this will be the official YAPC::Europe 2013 T-shirt design:
my $scalar;
...
open my $fh, "<", \$scalar or die;
will fail unless $scalar contains only code points 0xFF or lower - ie. they can be represented as bytes.
Perl's I/O will also treat the code points contained in the scalar as bytes - character \xA1 will be read as that byte, whether perl's internal representation is as UTF-8 or as bytes (or for the internals minded, whether SVf_UTF8 is on or not.)
Unfortunately in some cases this leads to a silent change in behaviour.
It seems people outside our community sees Perl as an stalled language because we have not released a new mayor version for so many years. We have to do something to show them they are wrong, right?
Well, no, maybe the problem is ours, unable to see what we don't want to see: They are right. Perl 5 is stalled.
Stevan Little has already described the situation quite well on Perl is not dead, it is a dead end. The funny thing is that it is mostly the same view that started Perl 6 more than a decade ago. It still holds.
From my point of view the mayor problems with Perl 5 are as follows:
This was originally posted in response to this discussion on the p5-porters mailing list and similar discussions on blogs.perl.org. I am also reposting it here.
I started cooking a big editorial essay in my head, but I'm just going to try and boil it down…
So long as a fixed number ("5" in this case) is *prominently* attached to Perl, it will be seen as stuck. Specifically, it is stuck behind that thing called "Perl6".
You may understand the distinction between "Perl" and "Perl5" and "perl-5.16.2", but the rest of the world (including many developers) does not.
Others (notably Apple, Java, Mozilla) understand how to manage perceptions through names and numbers. We should learn from them.
Continuing the affiliation between Perl5 and Perl6 is harmful to both camps. Negative or false perceptions about either needlessly end up affecting both.
The Perl5 community must pursue its own best interests and cannot be held hostage by the name and number of another language.
Yesterday, Ovid started his discussion about moving the major version of Perl 5 to Perl 7. You know what else happened that day? Continuum Analytics won $3M from DARPA to undertake a huge renovation to NumPy. Three. Million. Dollars. Not for Python. For an extension for Python. Continuum plans to add all kinds of capabilities, but bear in mind that PDL already possesses at least one of those, namely built-in support for missing data. From the technical standpoint, we were already ahead, and somebody else won $3M.
NumPy is very well run, and very well organized, and there are many more libraries available for NumPy than there are for PDL. Those dollars are very likely to be well spent. I will not argue that this was a bad decision by DARPA.
But think about it. Do you remember just how amazing it was when Craigslist gave the Perl Foundation $100,000? Or when Booking.com gave the Perl Foundation 100,000 Euros? Now, multiply that by 30.
Posting grand pronouncements about what Perl 5 has to become or the new name it absolutely must adopt won’t do anything. That’s irrelevant.
“What people manning the booths at non-Perl conferences say is the perception of Perl among those outside the echo chamber is irrelevant; I know the REAL problems Perl is having: they are the ones we think must be the reason based on our perspective from inside the echo chamber.”
If that still sounds rational to you, try a thought experiment:
“I don’t care what my profiler is telling me. That function does nothing important. I know where the REAL performance problem is, and it’s the one I’ve been thinking has to be optimised all along.”
This blog post introduces Sah, my data validation framework (or data validation language and validator generator, to be more exact). The very first work on Sah began almost 4 years ago as Data::Schema. The name change to Sah and the first release of Data::Sah happened in late 2011.
To validate data, first you write a Sah schema. Sah schemas are also data structures and are very much similar to JSON schemas, except that they are more featureful and (at least to to me) more convenient to write.
The design and implementation principle are mostly laziness and DRY:
The problem (as I see it) is that while we as an echo chamber don't
have anything new to offer compared to 5.10 (roughly speaking), the
wider world never looked past 5.6. This is an effort to fix that (and
only that). Did linux 3.0 have anything new to offer? We can even "blame
Linus" for the reasoning behind such a jump.
Looking at all of this, I have a small prediction to make.
