sungo.us http://sungo.us Ending the world, one stupid idea at a time en-us sungo 2009-11-25T01:22:22-05:00 http://sungo.us/archives/2009/11/25/moving/index.html Moving 2009-11-25T01:22:11-05:00 sungo http://live.sungo.us/rss. I've moved everything over to tumblr. Ironman posts will still happen here, but linked from tumblr, until I can figure out if/how tumblr does tag specific feeds. Thanks. ]]> http://sungo.us/archives/2009/11/17/on_perl5_and_perl6/index.html On Perl5 and Perl6 2009-11-17T23:49:21-05:00 sungo perl, tech quite a few folks weighing in. And, if for no other reason, than to hear my virtual gums smack around, I'll toss my pesos into the ring.

I write code for a living. When I was a young programmer, I followed the overused tolkien addage. One Language To Rule Them All. That language was perl5. As I grew as a developer, I learned what I consider to be the most important lesson a programmer can ever learn. That language you love, the wonderous perl5 or perl6 or whatever, is a tool. It's not your monogamous partner who will take your kids and all your money because you cheated on them with another language.

Shockingly, Ruby, Python, Erlang, C, Lisp, and hundreds of other languages have real world applications and have very real world specialties. Well, maybe not Lisp. perl5 is not the end-all-be-all language. If it were, would folks have wanted to create perl6 in the first place? If it were, would folks still be using Ruby, Python, sh, C, etc? Wouldn't everyone have adopted perl5 and danced off into the sunset?

We as perl5 people have to accept that perl5 is not the right language for everything. Maybe (now here's the shocker), just maybe, perl6 is the right language for your task. How can you know unless you learn it?

Most importantly, this is not a competition. The lovers of languages act like it is sometimes and that's a shame. We compare the number of public job offerings, the number of downloads, the attendance at conferences like it's a goddamn merit badge. It reminds me of the high school locker room. Size doesn't matter, folks. What matters is how you use it.



Now. There's another side to this. I write code for a living; this is true. I also (usually) write code as a hobby. When I sit at home, on my couch, with my laptop and some wine, I don't really care if ruby or scala is the best language for the job. At home, perl5 or C will do what I want. If they can't, I will hack on them until they submit to my will. Other languages may be awesome but my free-time coding is about spending time with the languages I love to use.

This scenario is another "not a competition" environment. Here on the couch, I want perl5 to be awesome at everything. That means taking ideas from other languages to improve my favorite language. Moose, POE, Catalyst, DBIC, Mason, all the frameworks we love to play with came from, in part, from the ideas of non-perl5 people. Our beloved perl5 was created using ideas from other languages. Our beloved perl6 was created with ideas from perl5 and yet more languages.



At the end of the day, no matter how you look at it, this isn't a competition. perl5 and perl6 exist. They borrow ideas from each other. The languages are natural complements. I certainly hope the communities can be too. ]]> http://sungo.us/archives/2009/08/04/corehackers_the_wind_of_change/index.html Corehackers: The Wind of Change 2009-08-04T23:36:21-05:00 sungo perl, corehackers, tech
As discussed in an earlier post, there are two sides to corehackers, as it stands right now. First, there is the codebase, where crazy ideas can get integrated and tested. Second, there is the community, where we try to get people involved, whether they're newbies or masters.

While trying to maintain corehackers as both a codebase and a community, an issue kept cropping up. Maintaining the corehackers repo is a major pain in the ass. When Chip first put forth the idea, we wanted a common integration point for all the shiny changes. Chip cloned the perl5 git repo and away we went. From a maintainer's perspective, this decision was ... not a great one. It requires me, as the repo maintainer, to keep the corehackers clone up to date with blead and all the relevant branches, in case someone wants to work on them. If we have custom patches in the corehackers branch, which is kind of the point, I get to manage merge conflicts as well. Yes, this work could be spread around to other people but the work still has to happen. At the end of the day, we put far more effort into keeping the repo up to date with blead/maint than we do developing shiny new code.

I talked to folks about how to ease this pain. Could git magically make this easy for me? No, it can't. There was talk of automation but that only makes parts of the pain go away. I came to believe that the issue wasn't technical. There was a fundamental flaw in our approach.

A series of epiphanies ran me over at this point.

First, corehackers, as a code base, exists effectively as perl5-unstable. Unstable patches get added, tested, and presented to p5p. That's the theory at least.

Second, perl5 doesn't need perl5-unstable right now. In the current universe, having stable maint- branches and an active blead is enough. Perhaps more importantly, having a perl5-unstable repo does a massive disservice to p5p and perl5 by fragmenting development and potentially lowering the activity on blead.

Third, having a magical corehackers repo goes against the very idea of distributed source control. DVCS lets us each have our own repository with as many branches as we want. When we're ready, we can ask like-minded souls to pull from our repository and provide comments and/or testing. When we're ready to submit the change to p5p, we can build a patch from our repository and send it in. There is no need for a centralized corehackers repo. In fact, it adds an additional totally unnecessary step.

Let's say we drop the corehackers repository. How do we support new core development and wacky ideas? We encourage people to clone the perl5 core repository and work in their own environment. We document and provide links to repositories where new work is being done. We teach people about the core and point them in the right directions. In short, we become a community wrapped around the idea of helping people learn and contribute, rather than partially wrapped around being the caretakers of all new ideas and the resultant code.

This is the direction I want us to go in. To support this, a few changes are necessary. I'll detail those in smaller posts in the coming days. For the vast majority of people involved in or interested in corehackers, these changes will not be surprising nor will they affect the work anyone is doing.]]> http://sungo.us/archives/2009/07/22/corehackers_wiki_policy_change/index.html Corehackers wiki policy change 2009-07-22T19:14:04-05:00 sungo perl, corehackers corehackers wiki requires users to create an account before editing or creating content. We made this policy change for a lot of reasons. I'll focus on one of the positive ones. I want to be able to give credit where credit is due. If a random IP address uploads a fantastic new FAQ or howto, I can't provide attribution. Having usernames gives us a way to provide attribution and give credit where it is due.

Hmm... Speaking of attribution, we really should put a CC license on the wiki content. The question is which one. I lean towards CC-BY. If you'd like to weigh in, please toss me an email.]]> http://sungo.us/archives/2009/07/12/sungo_vs_unicode/index.html sungo vs unicode 2009-07-12T20:46:14-05:00 sungo perl, tech
Firefox already supports unicode so I didn't have to worry about that. Next, E17 needed to support unicode in the titlebars. Easy peasy. I changed the standard font to Bitstream Vera Sans which supports utf8 and, I suspect, the full unicode set. Then came the difficult part. How to get my full terminal pipeline to handle those funny characters properly....

I'll save you the gnashing of teeth and give you the step by step:

  1. Switch to urxvt. (I've used Eterm forever but it doesn't support unicode and probably never will).
  2. export LC_CTYPE="en_US.utf8"; export LC_MESSAGES="en_US.utf8"; (That last var is important for applications like mutt.)
  3. export TERM=rxvt-unicode (Better, launch urxvt as urxvt -tn rxvt-unicode.)
  4. In ~/.screenrc, add defutf8 on. Alternately, launch screen as screen -U


It's important that the various environment variables be set everywhere, including the remote servers you're accessing.

mutt will automatically detect your environment and support the new charsets. For irssi, you need to run /set term_charset UTF-8.

From here, the only potential problem is the font you're using. If the font doesn't support unicode, none of the above matters. The font that I use for my terminals, 'fixed', has unicode support. As I mentioned above, the Bitstream family does too. If you're a fan of the font 'Anonymous', grab Anonymous Pro. Lots of other font families support unicode as well.

Hopefully, this will save someone some drama. :)]]> http://sungo.us/archives/2009/07/10/corehackers_progress_report/index.html Corehackers: Progress Report 2009-07-10T19:02:53-05:00 sungo perl, corehackers wiki is growing daily with all sorts of good ideas and even a magical perl5 api glossary (still in its infancy). chromatic opined on the importance of corehackers and followed it up with strictperl, a 'strict-by-default' patch to the perl5 core, based on the corehackers codebase. To round things out, Rafael decided to cherry pick our early patches into perl5-blead.

I'm ecstatic to see so many good things happening without any shepherding from me. ]]> http://sungo.us/archives/2009/07/04/corehackers_wiki/index.html Corehackers wiki 2009-07-04T12:35:27-05:00 sungo perl, corehackers
The corehackers site/wiki is now live. Great thanks to ShadowCat Systems for hosting it.]]> http://sungo.us/archives/2009/07/04/actions_are_greater_than_words/index.html Actions are greater than words 2009-07-04T12:10:45-05:00 sungo perl
We as a community have been jibbering a lot about improving perl5. How we want more releases of perl5; how we want our favorite ideas in perl5; how various segments of the community may or may not matter to our immediate universe. God knows that I've contributed to the jibbering, for better or for worse.

It's time for something to happen. Rafael said it in a well written post. In case you missed it, I'm going to say this as simply as I know how.

Code/Docs or STFU

There are lots of places to help. If you need help, epo and corehackers are more than willing the point you in a direction, ranging from introductory to super-advanced. If you don't need help, subscribe to p5p, join #p5p on irc.perl.org, look at the perl5 rt queue and get to work.

I'm tired of talking. I'm tired of reading blog posts with no actions behind them. This is your perl and it's not going to improve on its own. p5p are hard at work on the core and, unless you are too, your "contributions" are just noise and static that are distracting our core team from writing code and doing things that matter.]]> http://sungo.us/archives/2009/06/28/corehackers_process_work/index.html corehackers: process work 2009-06-28T16:26:22-05:00 sungo perl you need to start working? I've heard "C Primer", "Intro To The Core", and the task list. Send me email or a message on twitter or identi.ca if you think of anything else.]]> http://sungo.us/archives/2009/06/27/corehackers_help_improve_perl5/index.html corehackers: help improve perl5 2009-06-27T12:23:05-05:00 sungo perl quote Larry Wall here:
"[Orwant] keeps throwing coffee mugs against the other wall, and he says 'we are fucked unless we can come up with something that will excite the community, because everyone's getting bored and going off and doing other things'"
.

Many projects were born out of that sentiment and that realization, including the great and wonderful perl6. In the beginning, we envisioned that perl6 would replace perl5 just as perl5 replaced perl4. Years have past and perl5 is still with us. However, for the most part, excitement in perl5 has faded.

The world has lost perl5 in all the buzz of perl6.

I assert the following:
  • perl6 will not replace perl5.
  • perl5 will live on long after we've all retired thanks to the millions and millions of lines of code already in production. (Making squinty eyes at that? COBOL has a lesson to teach you.)
  • Once again, perl5 is risking The Orwant Condition of boredom and irrelevancy.
  • In fact, we're already at that point.


To quote the best movie of all time, Short Circuit: "[perl5] is alive! No disassemble!" Every day, thousands of programmers write millions of lines of perl5. Every day, hundreds of modules are uploaded to CPAN. Yet every day, many perl5 programmers wonder how they're going to find another perl5 job. (warewolf on irc.perl.org's #perl wishes to take credit for the Short Circuit reference. Since he provided logs, I'm inclined to let him :)

Something needs to be done. We need excitement not just about perl5 as a language but about perl5 as an interpreter. Projects like Moose are helping to drive excitement about perl5 as a language. If you look under the hood, though, Moose has to do some scary shit to work its magic. To do Moose *right*, we need to extend the core.

At YAPC10, Chip Salzenberg announced a project called 'corehackers' designed to excite people who are capable of hacking the perl5 core. There are a lot of experiments to try and a lot of great ideas brewing out there. We need to improve the core, make it more accessible, and take some weight off the pumpkings. I volunteered to help Chip and I started pondering and planning my involvement.

As I talked to non-core people at YAPC, something became very clear to me. There are lots of people in the community who want to help but have little C ability and no experience with the core. p5p has probably never heard of them and they've certainly never seen a patch. These people want to help though. They want perl5 to become better than it is, not just through contributions to CPAN, but by improving the language itself.

How do we get these people involved? How do we rally this pool of excited talent? How do we keep from driving p5p insane with the influx of newbies asking questions and submitting patches that may not be right, may suck mightly and obviously require mentoring? I pondered and pondered and talked and talked. Then it hit me.

We need a project dedicated to the newbies. We need documentation and introductions to the core. We need a mentor program. We need someone else (or several someone elses) to read through and integrate the patches from the newbies. I stood up in front of YAPC and volunteered to be that person. Now I'm standing up in front of my 5 readers, Iron Man, Planet Linode, and whoever else, volunteering to be that person.

Here's how we're going to do it. My project is part of corehackers. Like corehackers, this is not a fork of perl5. corehackers runs parallel to p5p and perl5 core development, providing a service, hopefully a useful one, to p5p. Chip and I will be working with the volunteers to guide their work, integrate their work and submit it to p5p for inclusion. We'll be working on the core too. We'll be putting our money where our mouths are and building a better perl5 from the grass-roots up.

What do we need? We need you. We need you to take a few minutes out of your day to document a piece of the core. We need you to document what isn't documented. We need you to learn the core and fix bugs. We need your ideas and we need your help working on new core features. I'm not looking for a long term, or even medium term, committment. You decide your own level of involvement.

Now, how do you get involved? Go to github and use git to either clone or "fork" our repo. When your change is complete, either issue a pull request or send me a patch directly (sungo@sungo.us). If you want to chat, grab either chip or myself on irc.perl.org. (Warning: #perl is not a help channel. Think of a tavern from an old western film and replace the residents with wifi-enabled hackers. Just query us directly.)

As far as I'm concerned, I plan to commit more than talk. Chances are that you won't see me blogging much more about the philosophy of all of this. I'll dump out status updates and ask for thoughts on ideas. I'm sure there'll be twitter traffic too. Actions > words.]]>