The Perl6 Gold Rush Began

Perl6 has just been released, after 15 years of intensive development. Now it's the perfect time for any developer to become a star, or at least to position himself in a very marketable position.
What one has to do to take advantage of the opportunities is to:

1. Install Perl6 - Following the instructions from the previous URL I had Perl6 installed in about 6 minutes on my dev VM
2. Learn Perl6
3. Help others to learn Perl6

Opportunities Ahead

StackOverflow

Right now there are currently only 116 questions tagged with Perl6 on SO. In the next period their numbers will increase drastically. Will you be the one to answer the most common ones and have your answers rack upvotes for the years to come? 

I currently am in the top 3% overall on SO, with around 13k points. I don't know what impact this fact has on my CV, because I rarely change jobs (3 times in the last 10 years), but I imagine that it should make any worthy tech recruiter more interested in a CV.

I've worked pretty hard to gain those points, having answered to more than 600 questions, but there are easier ways to earn them. One of those methods is to be an early adopter of a new language or framework that will become popular and to be among the first to give helpful answers. And Perl6 is destined to become popular - more on this later.

For example, this answer, which is the second most upvoted answer to that git question, has more than 6500 upvotes. That answer alone brought its owner more than 65k points, propelling him in the top 0.1% overall.

Build Panda Modules

Panda is a module management tool for Perl6. There is a list of most wanted Perl6 modules in case you don't feel very inspired. If you're a rockstar programmer and want to be able to demonstrate your stellar algorithmic powers, what better ways are there than to be the author of a module used by thousands of companies and developers?

Blog and Write Tutorials

Contrary to (at least my) intuition, in order to be popular, you have to approach easy subjects because that's what most people struggle with when they're starting. 

You don't have to be a Perl6 expert in order to be able write an entertaining article which will get you thousands of readers over the years (who knows, maybe you are able to position yourself as an authority in the domain). A very important part is to be among the first in the field - in the following days and weeks, you will be, because the Perl6 market is totally not crowded right now.

Perl6 Will Be a Huge Success, Guaranteed

On the technical side, the language is a breath of fresh air in the world of old-age scripting languages. Being built from scratch, the developers had the opportunity, and also took their time, to implement everything as it should be implemented, avoiding hacks and workarounds. 

Also, the amount of innovation the language brings in the world of programming is staggering. Larry Wall said that several PhD thesis could be created based on the ideas invested in the language.

If we'd compare programming languages with the startup ecosystem, it's like the founders of Google would create another startup from scratch. Would you believe in it's chance of success, or not?

Read More

Passwordless Login Done Right

Imagine you want to try the service offered by a site, but you have to log in to be able to do it. It is the first time you arrive on this site and of course you don't have an account. In order to get one, you have to sign up. Assuming the site doesn't offer you the option to sign up with facebook, twitter, google or other OAuth providers you'll most probably end up filling around 984375983475375345 fields, many of them mandatory. Even if it offers you the OAuth option, what happens when you're on a public computer? Would you want to log in to your favorite OAuth provider on a computer you don't trust?

How many times did you go through this? How many potentially good sites do you think you missed because the barrier imposed by the signup process was too high?
If you're a developer, how many users do you think you've lost because they gave up before even trying out your service?

We are in 2015, things should be much simpler. Imagine the following scenario:

1. You enter the same site as above and you're presented a login screen that consists of only one field. You complete a username and you press login.
2. A notification pops up on your phone and asks whether or not to allow the login. You press Allow and that's it. You're in.

Well, the above scenario is not science fiction anymore.

Introducing unloq.io

Once you have their app installed and configured on your smartphone you're able to log in on any website that implements the unloq system without using any passwords.
As a website developer, you're able to present your users a login screen that looks like this:

Passwordless login and signup with unloq

You may have heard before that passwords are obsolete. Now we have the technology that combines intuitive user experience with usability. Basically, this is an extremely secure, 2-form-factor, idiot proof login system once the user has the unloq app installed and configured.

Unloq.io is still beta

Although not everything works as smooth as it could right now, unloq is usable. The guys that are working on it are open for suggestions and they are working hard to implement them. 

Give unloq a try and tell me in the comments if you think that this is as cool as I see it.

Read More

Debian Upgrade From Wheezy to Jessie

You Only Live Once

This will not be such a YOLO experience, because the whole upgrading from Wheezy to Jessie (stable) went smoothly. I describe the whole process below.

I'm not such a great risk taker as to jump head first to the newest and shiniest things that appear. No, I'm using Debian as my main desktop OS for about a year now and I upgraded to Jessie from Wheezy sometimes in February. It all went great with that upgrade, and I had no issues with the OS ever since - this is the reason that made me confident that the upgrade from Wheezy to Jessie is smooth and easy. 

About The Upgraded Machine

Hardware

The hardware is a dedicated server hosted on Hetzner. I love Hetzner because they offer beefy machines to low prices. This server is a dedicated Intel(R) with an i7 CPU 950 @ 3.07GHz and 24 GB of RAM for which I pay just 34 EUR/month, VAT included.

Software

1. Operating System: Debian Wheezy 7.7
2. Web Servers: nginx and apache, but only nginx is running
3. Programming Languages used: Perl (of course), PHP, Python, nodejs
4. DB engines: MariaDB v10.0, mongodb,

Upgrading from Wheezy to Jessie

If you have valuable services running on your server, or you keep important data on your machine, or you can't afford some downtime, please read the official doc for upgrade (you can find the link in the External Resources section, below in this article). Heck, you should have a look at it anyways, because the points being emphasized there are really strong and are things that we all should incorporate in our daily lives as server owners. I found that documentation a little too verbose for my tastes and I wanted to see how the whole upgrade process works out without guidance. It worked out outstandingly well.

As I said, this process worked smoothly for me and there are huge chances that it'll be the same for you and that is just because of the great people behind the whole Debian project. Thank you Debian guys and girls for this great OS.

Upgrade Process Overview:

1. Check the current configured apt sources
2. Upgrade all the packages to their latest version through apt
3. Modify the /etc/apt/sources.list to contain the stable repositories
4. Upgrade again
5. Upgrade the whole distribution
6. Debian Upgrade From Wheezy to Jessie Process Step by Step
7. Upgrade the packages and cleanup the old ones
8. Reboot and start the custom services

1. Check the current configured apt sources

Check the configured repositories and see if the current distribution version is named wheezy or stable. On this hetzner machine it was named wheezy, so no matter how many times I issued apt-get dist-upgrade, it wouldn't have updated it. You can check this by opening the /etc/apt/sources.list file and see how the lines are looking. For example, I had these: 

deb http://mirror.hetzner.de/debian/packages wheezy main contrib non-free

deb http://mirror.hetzner.de/debian/security wheezy/updates main contrib non-free

The bold wheezy text above says that apt should look for updates in the wheezy repos, not in the stable repos. Let it like that for now. 

WARNING: If they point to the stable version instead of the wheezy version, you'll have to adjust the steps described in this tutorial. Your upgrade process is even simpler, all you have to do is issue an apt-get dist-upgrade.

2. Upgrade all the packages to their latest version through apt

Optional. This step is most probably optional, but since I did it, I include it. Just issue this as root:

apt-get update && apt-get upgrade

3. Modify the /etc/apt/sources.list to contain the stable repositories

Make a backup of your /etc/apt/sources.list file, or just edit the file and comment out all the entries you have, then go to this Debian Sources List Generator and configure the repositories you want to be included. Since Hetzner is located in Germany, I chose the Germany mirrors and now my /etc/apt/sources.list  contains this:

deb http://ftp.de.debian.org/debian stable main non-free

deb http://ftp.debian.org/debian/ stable-updates main non-free

deb http://security.debian.org/ stable/updates main non-free

The generator will considers wheezy as stable and you'll have to replace the wheezy text to either stable, or jessie. I prefer stable.

4. Upgrade again all the packages

Optional. This step is most probably also not necessary, but since I did it, I include this too. Again, as root:

apt-get update && apt-get upgrade

5. Upgrade the whole distribution

This is the big moment has come. As root, without hesitating (because you know, YOLO), issue the upgrading command:

apt-get dist-upgrade

On my server the upgrade took around 20 minutes, including the time the interface was locked waiting for my input and the time it took me to smoke a cigarettes (I had to, because the adrenaline was rushing through my veins).

6. Debian Upgrade From Wheezy to Jessie Process Step by Step

Although the upgrading process is straight forward and without any surprises, you'll have to stay near the console while it happens, because it requires your input: 

6.1 Permissions to restart your services during the upgrade automatically

I allowed it to do it and I have no regrets for doing it.

6.2 Installing the new GRUB

I didn't knew what to do here. After a brief search on the internet, I decided to go with the recommendation from the installer and checked all the partitions. 

It gave some errors telling that it couldn't install GRUB on the /dev/md1 and /dev/md2 partitions and the install went on with no problems in the end. It's probably also OK to install GRUB only on /dev/sda and /dev/sdb:

Chose Continue.

6.3 Disabling password authentication through open-ssh

It looks like the default in Debian Jessie is to not allow root login with password authentication:

While this is a great security improvement, I was logged in remotely with root, with password. Although I have the public key authentication set up for other accounts with sudo rights, I didn't want to risk to be left outside the server, so I chose No for this. I've taken notice of this suggestion and I'll probably update the OpenSSH config later.

6.4 Config files overwriting for the rest of the updated services

During the whole upgrading process, new version of services will be installed. If you've customized the previous services, you'll be prompted whether you wish to install the new config or keep the old one. I chose to keep the customized version for absolutely all the services I was prompted to update.

7. Upgrade the packages and cleanup the old ones

After the whole upgrade process is finished, I issued another apt-get update && apt-get upgrade to make sure everything is up to date. There were no packages updated, but it showed that some packages were installed and no longer needed. 

Issue an apt-get autoremove as root in order to have them removed.

8. Reboot

Because of the above errors when installing GRUB, this was the step to give me the biggest emotions. Given today is Sunday and I don't have that many people relying on my sites, I considered it to be the optimum moment to find out if something goes wrong when rebooting.
It didn't and the server rebooted quite fast (less than a minute)

External Resources

Again, if you're not that much into YOLO-ing, I strongly recommend you to at least have a look at the official docs for upgrading from Wheezy to Jessie.

If you liked the photos in this post and you want to help promoting Debian, check the DebianArt page, grab them and update your social profiles and web pages with those beautiful images.

Conclusions

The whole process to upgrade the Debian production server from Wheezy to Jessie took about an hour and offered no unpleasant surprises. Instead it offers some pleasant ones:

1. Perl version is 5.20.2, the latest stable version at the current moment.
2. kernel version is 3.16.0-4-amd64, which means you I have no more excuses to not start playing with Docker
3. libc is at version 2.19-18 vs 2.13-38 in wheezy
4. And many many more 

Final thoughts

This is my very first step by step guide regarding upgrading an OS. Also, I'm a Perl developer and not a sysadmin, so if you have some observations or want to give advice regarding the above tutorial, please either provide them in the comments below, or send me an email to tudorconstantin __at__ gmail.com to update this article.

Read More

CPAN Pull Request Challenge is Not Really a Challenge

photo by +Darren Song Ng 

What I mean when I say that CPAN PR Challenge is not really a challenge, is that contributing to well known Perl modules is much more accessible for the mere programmer than I expected. And I wouldn't had find out this without participating in the CPAN PR Challenge.

Since the day I started to use Open Source software for my day to day job, I couldn't help myself looking at  people that develop all this free software as if they were some kind of super programmers. They are the next step in the evolution of a programmer. I say this, because in my personal experiences, I found open source software to be of much more high quality, with regards to documentation, tests and coding practices than commercial products. Taking part in the CPAN PR Challenge, made me feel closer to them and who knows, by the end of it, I'll even start one of my own Perl module on CPAN.

Ripening the Low Hanging Fruits

I guess I'm not the only one who feels intimidated by the high quality that Perl modules exhibit with regards to software best practices and I think that's why +Neil Bowers, the guy who initiated and coordinates the whole CPAN PR challenge, put up some guidelines: lower the entry barrier to be accessible to people not involved in open source software until then. 

The rules of the pull request challenge are simple, you have to make a pull request to a Perl module that's assigned to you and is on github. As Neil says, the pull request can be as large or small as you want, but the idea is that you should be contributing to the distribution in some way. This might be documentation, tests, test coverage, fixing known bugs, adding new features, or something else.

The low-hanging fruit I found is related to the documentation on github: while the vast majority of the Perl modules contain their documentation embedded in the source files in the form of POD, github shows the documentation for a module, based on the from READMEs that have to be uploaded together with the repo.

The vast majority of the Perl modules have outstanding documentation, but they don't have a README.md file in the main folder of the module, such that when a developer reaches a github repo of a perl module, he has to dig around to find out what that module does.

Small Modifications, Big Impact

So, basically, we have the documentation already available in the source files and we just have to put it in a file so that github can read it. It would be nice to have this done automatically, preferable at build time. The doc in the module is POD, we need it in markdown, in a file called README.md, because that's what github displays. 

In March I got Perlbrew as a challenge. I use perlbrew heavily whenever I can - on all my dev VMs and also on production wherever that's possible, so I thought this was pretty cool.

My pull request on perlbrew is this. Although the code modifications I made are only 25 lines, the whole pull request says that there 277 lines added. That happens because the whole README.md file is generated.
I also modified some parts of the documentation to add more links into it and you can read below why I did that. 

Have look and see the aspect of the github repo of perlbrew before having a README.md file, and after having a README.md file. Don't you also think it's a much more readable and intuitive module with a proper formatted doc than without?

Positive Side Effects Created by a Good README.md

Besides the fact that it will be easier for a developer to make use of your module, you'll also get the following benefits for free:

1. Search engines love content and your module will provide plenty of it to them
2. Github has a high pagerank and each link from it to your online assets counts as a good backlink
3. With each fork your repo gets, the backlinks to your online properties are multiplied.
4. Considering how the TIOBE index is computed and the above improvements in SEO there are big chances that Perl as a whole will be better positioned from the TIOBE index point of view.

Conclusion

It feels great to be part of the cool community that Perl one is. I feel inspired by you, the developers that backs it in the way that I want to up my level and be like you guys. 

The CPAN PR Challenge is just one of the ways the community does in order to encourage other people to be part of it. Thank you +Neil for starting this and for taking the time and effort to manage it.

PS: If you liked this article, share it.

Read More

The Creator of Perl is Coming to Romania

The Perl Bible I received from one of its co-authors - brian d foy. In 16th of March 2015 it will receive the signature of Larry Wall.

Larry Wall, the God of +Perl, is coming to the third anniversary of +Cluj Perl Mongers and you should come too if you have the possibility.

This is great, because this is the year that Perl 6 will be launched into production and it will become a huge success: imagine the results of 15 years of research and development led by Larry Wall, who already has a proven track record into creating legendary programming languages. Not only that, but Perl 6 will also bring a lot of programming theories to production. Larry Wall himself told in an interview that they "had to design and implement various things that would have earned any number of advanced degrees had we been doing them in academia". So, do your best and come to the event.

If these are not enough reasons for you to come, another one is that +Amalia Aida Pomian is involved in organizing the event. She is a White Camel Awards winner and this is the perfect opportunity for you to see first hand how are the Perl events organized by her.

So, if you haven't done it yet, head on and save yourself a seat. It's free and there's a satisfaction guarantee or money back policy.

Companies, Developer Communities and Open Source Software

The Cluj.PM events are possible because of Evozon. Evozon pays for the conference room, Evozon pays for the schwag, Evozon pays for Larry's and Gloria's (Larry's wife) trip and accommodation to Cluj. It's not a big burn in Evozon's pockets, but, the opportunity cost exists: the owners could have got, for example, a full week holiday in Turkey, or they could bought new laptops or phones, or what not, with the money spent on this event. However, they chose not to do it, they chose to invite Larry Wall here. If you've been to any of the previous Cluj.PM events, you know by now that there is no one to ask for your CV and that there are no presentations about Evozon. It looks like a community event, but paid by Evozon. 

I'd love to see more companies getting involved into local communities, but to help them grow, not to take them over. Unfortunately, the corporate mentality is not there yet - there are companies in Cluj who almost forbid their employees to even take part to these kinds of events, because they're organized by a different company. They're afraid of losing their employees to the organizing company. It's like if they forbid their employees presence to conferences, their employees don't know about the existence of companies like Evozon. 

If you, the reader, are employed in a key position to such a company, then let me tell you something: that is plain dumb. You can't stop a piece of information to reach your employees ears, unless you cut their access to the internet, you lock them in a cell just with a computer to work on and with a bed to sleep. The fact that your employees are with you right now, is because your working conditions are good, the projects they work on are interesting and the money are satisfactory. They're with you because of their own choice not because they don't know about other employers. Please, trust them more and encourage them to take part into community. Heck, even you, as a company, can either organize an event, or be part of organizing the next event. 

I'm employed to Evozon and I'm not writing this post in order to get a raise (although I'd love one). I write it because in the last 3 years not a single developer wrote an article in which to say them a thank you. So Evozon, thank you for spending your resources on organizing Cluj.PM events. I write it, because I think that what Evozon does for the Perl community is too cool not to mention it because it's a corporation. There are more companies that are doing this kind of stuff and it could be even more. 

Booking.com is another example of a cool company that does great stuff for the Perl community. And as a result I think there is no Perl programmer who won't know that they're constantly hiring. cPanel is a constant sponsor of Perl events and the same is true for CraigsList.

To all of these companies and the many more which I didn't mentioned here, a very big thank you from me for the time, money and effort that you put into helping the Open Source communities in general.

Please share the event

If you're a developer in Romania or nearby or if you know people who you think would be interested in seeing a living legend of the programming world, please share this article. 

Because of not being promoted enough, I missed the visit of Richard Stallman in Cluj in 2014. I still regret it and I think it's in every (romanian, bulgarian, ukrainian) programmer best interest to be here.

If you are a programmer passionate about Perl or scripting languages in general, don't miss the event and reserve your seat by signing up on this form.

Read More

Shock and Terror - Perl IS a readable language

As a fresh developer, one of the first things you'll hear about Perl is one of the following:

1. Perl is unreadable
2. Perl is the only language that looks the same before and after is encrypted with sha256
3. Larry Wall fell asleep with his head on his keyboard and when he woke up he called the result Perl

You won't hear that Perl is the language that was behind almost every Web page until 2000s, practically powering the whole www, or that you can use Perl to build anything and elegantly implement all of your business requirements, or that Perl is the only real programming language that is delivered with every Linux distribution. No, I'm sure that if you started programming in the last 5 years, the very first thing you heard about Perl is one of the above bullshit jokes. And, if you happen to challenge their affirmation, they'll pull out some snippets that won a Perl golf code competition to "prove" it to you, proudly enforcing their statement with: "that is a perfectly valid  piece of Perl code". The truth is that no, the output of a golf code competition is not a valid piece of code. Not for the business critical applications that we generally use Perl for. Believing someone who never opened a Perl manual and says that Perl is unreadable, is like believing a 3 years old when she tells you that English is unreadable. Come on, you gotta be smarter than that.Show me a programming language that you can understand without reading some parts of its documentation and I'll give you the winning numbers at the lottery.I'm sure you can read and understand any programming language after you put enough effort and exercise into learning it - yes, even brainfuck. 

Programming Languages are Like Spoken Ones

There are around 1 billion people who understand Chinese and 200 million people who understand Arabic after all. And there are literally billions of people on earth who can't understand a single letter from the Latin alphabet. Do you believe that those billions of people who can't read English are wrong? or the ones who only speak Chinese, Japanese, Arabic, Russian, or Hebrew are using a less than best language because you can't understand them?  Now, do you really think that Perl is unreadable? Compared to what? To a language you used for years before trying to do something with Perl? Who sets the programming language readability standards? You see my friend, There Is More Than One Way To Do It and if someone tells you something else, send them to this post.
Just because some respected developer in an unrelated technology can't figure out what each sigil means in Perl, it doesn't mean that the language is unreadable. It means that the developer is a superficial cunt individual, who can't figure the difference between a joke and reality.

Programming Languages are Like Civilizations

We can consider Perl to be like the modern world, where everybody is allowed to do anything they want as long as they don't disturb or harm other people (this is unfortunately untrue at a world scale, but I live in Europe and here this is pretty much the case). Perl evolved nicely from a time similar to Egyptians where we used rudimentary tools and were able to  build great things - the internet, just like the Egyptians built the pyramids, to the present day, where we have DBIx::Class, and Mojolicious, and Catalyst, and Dancer, and Plack and we build beautiful skyscrapers with hundreds of floors.

We can see that other languages are still in the dark middle ages, where they burn witches when they say that not everybody likes to have their indentation enforced on their code the Earth is not flat, or even that it revolves around the Sun instead of the reversal.

The future is now

Right now I'm in Brussels, waiting for +FOSDEM 2015 to begin (thanks Evozon for sponsoring my presence here). If you're also around, do your best to attend Larry Wall's keynote speaking on Sunday, because I've heard he has really important news to share regarding Perl6. You might actually not have that much time to try Perl6 (which I hope will be named Camelia) before it is declared production ready and becomes mainstream.
If he made it that big with the original Perl, imagine what kind of a language will come out after his more than 25 years of experience, out of which, 14 were spent on designing a new language.

I can't wait to see the power of Perl6 explained by +Curtis Poe (who's one of my favorite presenters) on Saturday - have a sneak peak at his slides hereIf you liked this article, don't forget to share it on your favorite social network.

Read More

Perl Already Won

This post is a response to the Yet Another Perl Rant article which appeared on hackernews.

Without being a special kind of paranoid or conspiracy theory adept, I can't help myself noticing that from time to time an article appears which tries to convince us that Perl is dead and there are no reasons to learn it.

TL;DR

Perl already won once - in the nineties it was the technology that powered the whole web. It got a market share that none of the 'cool' languages will ever be able achieve - be that Python, or Ruby, or Go, or Node, or whatever. Be that backed by Google, Facebook, Twitter, Craigslist or Booking.com. PHP is coming close, but it won't achieve it, exactly because of the cool new programming languages, because of the much larger internet market and of the diversity of software developers. 

I believe the main reason haters gonna hate Perl forever is because their language of choice will never achieve its dominant adoption.

Transition to Perl

I started programming in Perl in 2010, after 4 years of professional software development (in progress) and after I did some projects in PHP, Ruby and Python.

I have to admit, as a programmer it wasn't really easy to start with Perl:

1. Having those list, scalar, string, or void contexts is pretty confusing when you're first exposed to them. 
2. The types of variables are totally different from anything that I've seen that far - scalar, array and hash type. 
3. It was also hard to get along with the TIMTOWDI (There Is More Than One Way To do It) principle which is everywhere - should the $customer->orders method return undef when no orders are present, or should it simply return, or should it return an empty array or maybe an empty array ref - this is just one question that I found myself asking over and over again.

I had all of the above issues clarified after I read Damian's Conway Perl Best Practices and Intermediate Perl.

I came for the money and stayed for the robustness

I decided to switch from Progress because there was only one company in Cluj-Napoca that was using it. While you would normally expect, as an extremely specialized technologist, to earn a bigger salary because of the scarcity of experts in a certain field, the opposite was true - I earned a smaller than average salary, exactly because I could do nothing about it (ie I didn't had where to go). Although I wanted to switch to Java, the first opportunity I had was Perl. Given that we had at that time about 5 companies that were doing Perl development in Cluj, and that the salary this company offered, as a junior Perl developer (I wasn't able to even code the 'hello world' without googling it), was bigger than the one I got as a senior Progress developer with a commitment of salary negotiation after one month with the company, signaled me that there had to be something good with the language that I've only heard about it looks the same before and after it is encrypted. 

While I worked as a Progress developer, I was doing the whatever part time project I wanted to work on using technologies like PHP, Ruby and Python, mostly because of the high costs of running a Progress app (at that time they were charging even for the runtime VM, I don't know if that still applies). I don't have any public project since that time. When I switched to Perl I decided to use it for everything I do - I wanted to see if that's possible, without losing any productivity and in order to become more proficient in the language.

As a result, I currently have 2 extra projects that I work on and have real users www.eatfab.com (a food ordering application) and www.prforge.com (a crowd speaking platform).

The right tool for the right job

Since 2010 when I started to develop in Perl, I found out that Perl has everything that I needed, some more and they're all rock solid pieces of software:

1. Want a RoR like framework? go with Catalyst
2. Want a Sinatra like framework? choose between Dancer2 and Mojolicious
3. Want an uber ORM? - go with DBIx::Class (dbic)

That's why Perl became my golden hammer

Young but wise

I think that the average age of a Perl developer is about 35 years (I have no official data for this, my hunch is based on the people I saw at numerous YAPCs I had the opportunity to be present at). Assuming this is true and assuming a dev enters into production at 23 years old, it results that the average Perl developer has 12 years of software development experience.
What kind of code would you prefer in your business critical, money making software products? one written by people with an average of 12 years experience in the language of choice, or one written in a language that appeared on the radar in the last decade:

1. Ruby on Rails, the framework that made Ruby popular was launched in late 2005
2. NodeJS is not yet at version 1, having its first version launched in May 2009

Regarding youth, Perl's last stable version is 5.20.1, released in 14th of September 2014. The Dancer2 framework had its first release in 2013 and it had 37 more releases since then. Mojolicious reached version 1 in December 2010, now it's at version 5.72 - have a look at the frequency of releases.

In my imagination a language that is dying does not have frequent releases, nor it has modern frameworks and it doesn't inspire other languages also.

A short story

I currently work on a project written completely in Perl for a company that sells economic reports - lets call it X, because I don't have their permission to use their name. The project was started around 1998 and for about 8 years there were less than 3 developers who supported the whole online division of the company. The company that I currently work for (an outsourcing one) started to assist the X company with the project around 2008. If I remember correctly, between 2008 and 2012 there were no more than 5 developers assigned to the project from my company at any one time.

In late 2012, a new CIO was hired by the X company in order to help with modernizing their so called legacy codebase. It was indeed legacy - the whole website was done entirely with CGI.pm. The new CIO promised to rewrite the whole system in .NET in just one year, because you know, how much functionality can be implemented by an average number of 3-4 developers in a technology that is so old and rusty as CGI, while also maintaining the core, business critical and money generating, functionality?

So, in November 2013 they started to lay out the business logic that takes place in the online app in order to be able to start implementing it in early 2013 so it would be done by the end of 2013.

It was March 2013 when the CEO decided to stop the idea of rewriting the app in .NET because they weren't able in those 4 months to even define the scope of the project. The CIO was out.

My company made the commitment to rewrite the whole app using Modern Perl and to also respect the original schedule, compensating the time lost because of the unsuccessful .NET rewrite attempt. I remember my department manager saying after he came back from company X with the project "I might have made the most stupid commitment ever, but it might also be the best".

Long story short - by October 2013 we rewrote 90% of the old application using Catalyst and DBIx::Class on the backend and Bootstrap from Twitter on the front end. By the mid of 2014, the old application, the CGI one, was taken out of production.

There was no business interruption because of the rewrite.

Conclusion

Watch out for whoever says that Perl is an ancient technology, because they're either ignorant and completely clueless about what's really happening in the world of computer programming, or they have hidden agendas.

I know, this might be a biased post - I love Perl, but so are the posts that people wright when they say it is irrelevant. Let me ask you a few biased questions:

1. Why do you love Perl?
2. How did Perl helped you in your profession?
3. How did Perl helped your company?
4. How do you intend to use Perl in the next years?

Read More